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PREFACE 


These  proceedings  are  based  on  the  presentations  that  were  made  at  the  Second  Consortium  Reengineering 
Workshop:  Approaches  to  Reengineering  for  Information  Systems,  held  at  the  Software  Productivity 
Consortium  in  Herndon,  'Virginia  on  December  4  and  5, 1995. 
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1.  INTRODUCTION 


1.1  OVERVIEW 

This  document  contains  the  results  of  the  second  Software  Productivity  Consortium  (Consortium) 
Reengineering  Workshop,  held  at  the  Consortium  on  December  4  and  5, 1995.  This  introduction  provides 
general  information  on  the  workshop  and  a  description  of  how  the  remainder  of  the  document  is  organized. 

1^  WORKSHOP  OBJECTIVES 

The  objectives  of  the  workshop  were  to  gather  reengineering  researchers  and  practitioners  from  industry  and 
academia  to  discuss  directions  in  reengineering.  The  workshop  sought  to  compare  approaches  to  reengineer¬ 
ing  information  systems,  including  the  current  state-of-the-practice  of  reengineering  of  legacy  systems,  data 
and  process  reengineering,  product  lines,  and  object  technology  in  reengineering. 

1.3  THE  WORKSHOP  PROCESS 

Thirty  two  people  attended  the  workshop.  Their  names,  organizations,  and  addresses  are  given  in  Appendix 
A.  Attendees  were  invited  to  submit  position  papers  prior  to  the  workshop,  make  a  presentation  at  the  work¬ 
shop,  or  both.  Eight  attendees  submitted  position  statements,  but  one  cannot  be  included  because  of  copyright 
restrictions.  Thirteen  attendees  made  presentations. 

1.4  ORGANIZATION  OF  THIS  DOCUMENT 

This  document  is  organized  as  follows: 

•  Section  2  contains  position  papers  submitted  to  the  workshop. 

•  Section  3  contains  copies  of  the  slides  presented  at  the  workshop. 

•  Section  4  contains  the  results  of  the  workshop. 

•  Appendix  A  contains  a  list  of  attendees. 

•  Appendix  B  contains  the  final  workshop  agenda. 

1.5  TYPOGRAPHIC  CONVENTIONS 

This  document  uses  the  following  typographic  conventions: 

Serif  font . General  presentation  of  information. 
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1 .  Introduction 


Italicized  serif  font  . Publication  titles. 

Boldfaced  serif  font .  Section  headings  and  emphasis. 
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2.  POSITION  STATEMENTS 


This  section  contains  the  position  statements  submitted  by  workshop  attendees.  The  statements  are  arranged 
alphabetically  by  authors’  names.  The  following  table  lists  the  authors  and  the  titles  of  their  position  state¬ 
ments  (empty  entries  in  the  Utle  column  means  the  authors  did  not  supply  a  title  for  their  position  statement). 

Shawn  Bonner  and  Clement  McGowan  Bridging  the  Gap  Between  Business  Process  and 

Software  System  Reengineering 

Dan  Juttelstad 

Julia  McCreary  Reengineering  Large  Legacy  Systems  Case  Study: 

Internal  Revenue  Service 

Boris  Mutafelija 
Anne  Rose 
Karen  White 
Mark  Wilson 


Reengineering  User  Interfaces:  A  Case  Study 
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Name:  Shawn  A.  Bohner  and  Clement  L.  McGowan 

Coitpany:  The  MITRE  Corporation  _ 

Division; _ _ _ 

Address:  7525  Colshire  Drive,  MS-Z667 _ 

McLean,  Virginia,  22102-3481 _ 


Telephone:  Bohner  (703)  883-7354  _  McGowan  (703)  883-7099 


FAX  #;  (703)  883-6991 


E-Mail:  bohner@mitre.org  _ mcgowanSraitre . org  _ 

Title:  Lead  Scientist  _  Principle  Engineer  _ 

(INCLUDED)  I  will  be  sending  you  a  position  statement  by  Nov.  30. 

(INCLUDED)  I  am  interested  in  making  a  reengineering  presentation  at 
the  workshop.  My  topic  is  on:  Bridging  BPR  and  Software  Systems. 


Title  of  Presentation:  Bridging  The  Gap  Between  Business  Process  and 
Software  Systems  Reengineering 

Abstract:  The  bridge  between  business  process  and  information  systems 
reengineering  is  all  too  often  missing  from  the  roadmap  of  reengineering 
efforts.  When  process  and  system  engineers  get  to  this  transition,  they 
discover  a  rickety  old  bridge  with  steep  terrain  on  either  side  of  a  wide 
chasm.  Recognizing  this  dilemma,  we  developed  the  Business  Reengineering 
for  Information  Technology  (BRIT)  approach  that  systematically  transitions 
from  business  process  to  information  systems  engineering.  BRIT  is  designed 
to  handle  a  wide  range  of  reengineering  factors  including:  "best 
practices,"  COTS  applications,  non-standard  business  processes,  and  change 
situations  ranging  from  continuous  improvement  to  radical  restructuring. 
This  proven  approach  is  described  with  relevant  examples  of  its 
applications . 


Describe  your  experience  with  reengineering  projects  to  date. 

The  authors  have  held  leadership  positions  in  a  wide  range  of  software 
system  reengineering  efforts  both  in  industry  and  the  public  sector.  Most 
of  the  efforts  over  the  past  5  years  have  been  in  the  pviblic  sector  and 
have  focused  primarily  on  modernizing  legacy  systems.  The  following  are 
examples  of  these  experiences. 

The  first  example  is  a  system  that  was  originally  developed  in  the  1960 ’s  and 
enhanced  over  twenty  years.  It  was  written  in  COBOL  with  data  managed 
without  the  support  of  a  commercial  DBMS.  The  system  was  housed  on  an 
obsolete  platform  and  software  doc\unentation  was  minimal.  Using  a  combined 
top-down /bottom-up  approach  logical  data  models,  business  rules,  and  the 
like  were  captured  and  docimnented.  These  models  were  redeveloped  for  a  new 
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open  systems  architecture  and  specified  for  an  relational  database 
management  system  inplementation. 

The  next  exanple  is  a  system  that  was  originally  developed  as  a  prototype 
and  deployed  to  the  field  in  an  operational  environment.  Without  the 
requisite  software  development  discipline  and  software  docvimentation, 
software  changes  were  difficult  at  best  and  many  times  impossible. 

Technology  iirprovements  led  to  platform  obsolescence  and  ultimately  the 
requirement  that  the  system  be  modernized.  Since  the  software  was  not 
well  developed,  a  porting  effort  was  not  feasible.  Instead,  a  targeted 
capture  effort  was  used  to  identify,  qualify,  extract,  refine/redocument, 
and  wrap  algorithms  and  functions  determined  to  be  useful  in  the  new  system. 
The  rest  of  the  project  followed  a  more  traditional  development  approach 
concentrating  on  a  flexible  architecture  and  reuse  of  the  captured 
components . 

Another  example  is  a  system  that  was  originally  developed  in  the  late  1988 's 
in  COBOL  with  data  managed  using  a  hierarchical  database  (tuned  for  speed) . 
The  system  was  developed  on  an  aging  platform  and  the  database  architecture 
was  deemed  to  be  inflexible  for  the  types  of  changes  that  the  system  was 
subject  to.  Using  a  combined  top-down,  bottom  up  approach  the  logical  data 
models,  business  rules,  and  the  like  were  captured.  The  database  was 
restructured  to  take  advantage  of  relational  database  features  and 
redeveloped  for  a  new  open  systems  architecture. 


What  are  the  problems  with  reengineering  approaches  you  have  tried 
or  observed? 

Many  of  today's  system  modernization  efforts  are  sparked  by  business 
process  reengineering  (BPR)  efforts.  A  new  process  levies  new  requirements 
that  the  existing  software  system  cannot  support  without  significant 
changes.  While  new  processes  resulting  from  the  BPR  effort  describe 
business  level  requirements,  there  exists  a  sizable  gap  between  these 
requirements  and  the  requirements  needed  to  modernize  the  supporting 
software  systems. 

Approaches  that  have  a  high  reliance  on  tool  technology  to  reverse  engineer 
software  artifacts  from  source  code  are  subject  to  considerable  risk. 

Most  tools  advertised  to  accomplish  software  reverse  engineering  do  not 
capture  the  requisite  information  needed  to  understand  the  system. 

Some  tools  are  able  to  capture  physical  representations  of  the  program 
and  data  design,  but  there  is  considerable  work  in  transforming  these 
representations  into  logical  models  since  much  of  the  semantic  information 
is  not  conveyed  in  the  source  code. 


What  are  you  looking  for  in  reengineering  solutions,  methods,  and  tools? 

A  trend  that  started  a  few  years  ago  in  the  information  systems  engineering 
community  was  the  merging  of  business  engineering  and  information  systems 
engineering  concepts.  We  see  evidence  of  this  in  CASE  tools  where  process 
modeling  tools  are  being  integrated  with  information  systems  modeling  tools. 
We  are  looking  for  integrated  approaches  that  enable  issues  from  both 
domains  to  be  addressed. 

While  today's  tools  and  methods  offer  some  help  in  modeling  processes  and 
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systems,  technology  to  support  reverse  engineering  is  still  lagging  behind. 
Since  information  conveyed  to  the  conrputer  in  the  fom  of  a  program  does  not 
contain  direct  logical  design  or  architecture  information,  evidence  of  this 
information  must  be  inferred  from  patterns  in  the  code  and  available 
documentation.  Therefore,  we  should  be  looking  for  knowledge-based 
approaches  for  discovering  the  information  necessary  to  reverse  engineer 
existing  systems.  Just  as  in5>ortantly,  we  need  to  be  implementing  ways  that 
new  systems  can  be  represented  so  that  they  can  be  readily  reverse 
engineered  in  the  future. 
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Telephone:  4  01-84 1-4581 


FAX  #:  401-841-2031 


E-Mail:  _ juttelstad@cocie22  .npt  .nuwc.  navy,  mil _ 

Title:  _ Elect  Eng _ 

(  X)  I  will  be  sending  you  a  position  statement  by  Nov,  30. 

(  )  I  cura  interested  in  making  a  reengineering  presentation  at 
the  workshop.  My  topic  is  on:  _ 


Position  Paper 

Dan  Juttelstad 
NUWCDIVNPT 
Code  2253,  1171-2 
Newport  RI 

NUWCDIVNPT  Code  2253  has  been  addressing  re-engineering  of  software  for 
reuse  for  4  years. 

In  that  time  a  process  has  been  developed  that  integrates  commercial  off  the 
shelf  (COTS)  tools 

for  performing  Domain  Analysis,  Software  Assessment,  Software 
Re-Engineering,  and  Software 
Resuse  Repository  support. 

The  primary  objective  is  to  develop  the  Undersea  Software  Domain  Reuse 
Repository.  This 

repository  is  intended  to  contain  resusable  software  con^onents  that  meet 
the  requirments  of  the 

undersea  domain  model.  The  software  components  come  from  existing  systems 
software  and 

new  development  software.  The  conponents  are  evaluated  for  quality  with 
respect  to  reuse  and 

re-engineered,  if  necessary,  for  incorporation  into  the  reuse  library. 

The  primary  issue  in  performing  re-engineering  for  reuse  is  the  definition 
of  metrics  associated 

with  the  re-engineering  process  and  determing  cost  versus  value  added.  It 
is  difficult  to  predict 

the  value  added  by  re-engineering  and  determineing  if  it  is  cost  effective. 
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Reel 


UcARGE  Li 


engmeering  ^.^ARGE  JL^EGACT  SYSTEMS 

Case  Study:  Internal  Revenue  S 


•ERVICK 


Background 

T^e  Intanal  Revoine  Service  (IRS)  simy  of  maimatuing  (and  aaen^rtiiig  to  i^lace)  aging, 
piecemeal  lega<7  systems  is  one  wMch  is  ^Emiliar  to  mai^  institations.  In  the  process  of 
evaanadngreeo^neerii^  as  an  enaWmg  technology,  we  discovered  critical  issnes  broader  than  the 
mechanical  definitions  of  methods  and  tool  lechnolt^.  Ratha-,  the  otganizaiiMial  fiamewotk 
became  tite  essexn^  elonent;  &r  exan5)le,  ideating  bosmess  objet^es,  patbnning  a  portfolio 
anafysh^  friianntng  technology  tranyjtinn. 

The  IRS  has  been  a^ed  in  leaigineering  projats  airf  studies  Mce  1990.  Three  reengineering 
rfforts  were  completed  in  Kscal  Year  1992,  idaitifymg  specific  IRS  opporliimties  to  this 
tedmokigy  in  siqipait  of  inplementing  Tax  Systems  Modernization,  a  massive  effort  planned  to 
replace  file  tax  sys^  software  over  a  10-year  paiod.  One  project  made  a  high-level  evahiafion 
of!^  systems  to  identify  candidates  for  reengineering,  based  on  an  assessment  of  IRS  needs  and 
busmess  cbjectives.  A  second  project  identified  took  that  could  siqtpoit  the  objectives  idenrifipH 
in  first  project  The  diird  project  was  a  prototype  to  demonstrate  technical  issnes  and 
solutions.  Two  smallar  pqiects  were  conq>leted  in  FY93,  with  an  ^tterprise-wide  a«pg«Tipnt  of 
cuxii^  systems  scheduled  to  b^jn  in  FY94.  Fnading  for  that  project  wa<;  pfygjjmnptt  miril  Fv<K 

and  snbstaitf  ally  lednced.  Projects  airiientfy  underw^  include  a  Year  20(K)  Project  and  fbor 
leose/reengmeoing  projects  in  support  of  new  development  ThtougliDut  this  period,  an 
aggtes^e  efifiMt  to  int^raie  reargmeeiiDg  principles  into  die  software  develi^ment  enviranment 
and  maiket  their  benefits  in  fight  of  organizational  goak  has  met  cuhnral  as  well  as  buaness 
challeages. 

rteblNlTlON 

Software  reengmeaing  is  *fined  as  an  enabling  tedmdogy,  sopparting  redevelopment  in  various 
strategic  and  tactical  w^.  It  rrfeis  to  a  variety  of  techrriques  and  took  employed  in  stqtport  of 
the  process  of  using  co^^xHlents  from  existing  tystems  to  inqjrove  die  current  system,  vriiether 
that  improvement  medudes  a  complete  redesign  and  rewrite  of  code,  a  transitiQB  to  a  new 
e^i^mem/  software  platftum  or  a  sinqile  redocumentation  of  <-TTrrffny  systems. 

Concerns 

Objeciive-drivai 

Reengmeeiing  is  objective-,  or  goal-,  oriented.  There  are  so  marry  ^plications  to  which  the 
tednol^y  can.  be  ^plied  (plaiftxm  mrgratton,  data  translation,  langoage  npgrad^^ 
redocnmeirtation)  that  the  d^rdtion  of  the  term  is  dependart  upon  the  use  being  of  it  in  a 

paiticQiar  plication.  Thk  aspect  of  the  "dkdpliiie-  needs  to  be  amsidered  when  creating  a 
fiamework  or  outlining  a  fife-cyde  for  ledevelcpinmit 
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CMtoral  Barriers 

The  maticering  of  leen^eeciDg  as  a  supporting  and  enabling  technohigy  for  the  process  of 
software  devdopmeait  is  essential  to  its  acceptance  is  the  organizational  culture  unfetniliar  with 
h.  unfemiliar  wMi  reengg«ering  techmqaes  and  possible  benefits  may  lenst^  based 

cm  an  assompticHi  lim  this  effort  will  detract  ffom  and  divert  resoinces  ffom  tn^onzational 
development  goals  or  that  reen^neeiing  is  counter  to  the  *new  dev^opmCTt”  effcnts.  These 
barriers  mnst  be  addressed  eaiiy  and  often  Th^  will,  no  doubt,  contmoe  to  be  a  part  of  the 
cgvironmCTt  into  \rfiichreenfflneeting  wSL  be  integrated.  Maimgement  soj^iart,  once  garnered, 
ran  be  essential  in  keying  die  momenliun  going  again^  coltnral  resistance. 

Transition  Issoes 

Transition  and  die  ordedy  redrenKOt  and  r^lacement  of  legacy  ^sterns  with  newly  devdoped 
carred^dcqied  systems  is  tme  of  the  most  cddcal  issues  fticing  the  IRS  today.  Most  replacement 
scerosios  do  not  have  a  dean  one-to-one  mapping  of  funcdons  and  data  to  die  systems  tiiey  are 
T^lacing.  The  management  of  ideadfying  ftmcdcais  and  prq[mring  the  systems  and  data 
replaced  is  a  part  of  the  reengineering  discipline  diat  is  essential  to  a  snccessfui  Tax  Systems 
Modernization  effort. 

CoNCUJSlONS 

It  has  been  said  by  nony,  but  the  essential  ingredients  to  successful  implementation  of  an  enabling 
tedmdogy  like  re^gineering  are  organizatiogal .  Qrgani2atioDat  needs  must  be  identified  and 
assessed.  Oeariy,  not  every  orgamzadon  requires  every  technical  soludon  available  throngh 
reengineeiing.  A  supportive  mmiagement  group  must  be  identified.  A  SMALL  pilot  project 
winch  win  result  in  a  jKodnctkHisdutiDa  to  a  real  pidilem,  and  has  a  high  likelihood  of  success, 
ti^wdn;  tn  he  idfanrififid  T?i-ngrmrfid  The  results  of  that  prof^  need  to  be  publicized,  using  that 
success  to  integrate  reengineering  in  die  software  devek^nnent  {uocess  elsewhere  in  the 
organization.  And  wh^  die  pOot  is  not  a  success,  or  the  organizatkin  charges  direcdoo, 
rRrefering  the  tnmsjfion  plans  rmt-of-stgi,  the  arganizational  needs  must  be  revisited  to  bring  the 
reengineering  solutions  to  bear  oa  those  with  a  good  retam-on-investment.  Recent  imhistiy 
'hype*  has  resulted  ml^hes^ectaticms  bong  h^d  by  management,  followed  by  disaj^intment 
and  a  sense  that  the  technology  has  "nodnng  useful  to  offer*  .  A  plan  should  be  developed  for 
implementihg  those  a^ects  of  reengfneeth^  diat  are  s^i^le  for  die  or^nizadmi,  based  on 
recognized  bnaness  goals  and  reasonable  supporting  technology. 
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Return-Path :  <brewereme<lusa .  Software .  ORG> 

Received;  by  Software.ORG  (/\=/\  Sinail3. 1.25.1  #25.19) 

id  <m0tKT0P-0001PAC@Software.ORG>;  Tue,  28  Nov  95  12:00  EST 
Received:  by  inedusa.Software.ORG  (/\==/\  SmailS. 1.25.1  #25.10) 

id  <m0tKTOS-000039C@medusa. Software. 0RG>;  Tue,  28  Nov  95  12:00  EST 
Date:  Tue,  28  Nov  1995  12:00:31  -0500  (EST) 

From:  (Jerry  Brewer  <brewer8Software.ORG> 

Subject;  2nd  Reengineering  workshop  (fwd) 

To:  faceinire@Software.ORG 

Message-ID:  <pine. 3. 89. 9511281225. H23269-0100000@medusa> 

MIME-Version:  1.0 

Content-Type:  TEXT/PLAIN;  charset=US-ASCII 


— - Forwarded  message - 

Date:  Tue,  28  Nov  95  11:55:00  EST 

From:  Mutafelija,  Boris  <MUTAFBOegateway .grumman.com> 
To:  "'smtp: brewer@software.org'"  <brewer@software.org> 
Subject;  2nd  Reengineering  Workshop 


Gerry, 

As  per  your  announcement  please  register  me  for  the  2nd  SPC  Reengineering 
Workshop. 

Name:  Boris  Mutafelija 
Conpany:  Northrop  Grumman  Corp. 

Division:  Data  Systems  and  Services 
Address:  2411  Dulles  comer  Park 
Herndon,  VA  22071-3430 
Phone:  (703)  713-4174 

Fax:  (703)  713-4103 

e-mail:  borism@gateway.gruminan.com 

Title:  Information  Systems  Technologist 


Attached  below  is  my  "Position  Statenent". 

Northrop  Grumman  Data  Systems  and  Services  Division  External  Information 
Systems  Business  Unit  is  extending  its  standard  organizational  software 
process  to  include  reuse  and  reengineering.  We  often  encounter  requirements 
to  reengineer  a  large  body  of  legacy  software  and  transition  this 
reengineered  software  into  a  solution  required  by  the  customer.  Typically, 
our  customers  require  that  reengineered  systems  satisfy  additional 
requirements,  such  as  enhancements  to  existing  software,  integration  of 
reengineered  legacy  systems  with  new  applications  (frequently  COTS 
software),  etc. 


Problems  that  we  experience  can  be  classified  as: 


1  —  System  engineering  problems 

?  development  of  conplete  solutions  that  will  include  reengineered  legacy 
software,  newly  developed  software,  and  COTS  software  (forward-  and 
re-engineering  combined) 

?  addition  of  new  capabilities,  including  increased  reliability, 
maintainability,  transportability 

?  process/methodology  addressing  multistep  reengineering  (i.e. 
reengineering  that  covers  code  conversion,  data  conversion,  database 
conversion,  rehosting,  adding  new  capabilities,  etc.) 

?  integration  of  reengineered  legacy  code  with  COTS  software 
?  testing  strategies 
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?  transitioning  (to  a  new  system) 


2  -  Reengineering  problems 

?  reengineer  vs.  reverse  engineer  vs.  restructure:  when  is  each  one 
appropriate?  how  do  they  play  together? 

?  reengineer  and  enhance  (there  are  additional  requirements  to  be  satisfied) 
?  convert  from  one  language  (most  frequently  COBOL)  to  another  (most 
frequently  Ada) 

?  convert  from  hierarchical  to  relational  database 

?  convert  from  mainframe  to  client-server;  in  addition,  convert  code  from 
one  language  to  another,  and  from  one  database  format  to  another 
(  multistep  reengineering) 


3  -  Implementation  problems 

?  system  analysis/synthesis  tools 
?  need  for  tool  repositories 
?  system  testing  tools 

?  reengineering  tools  (rehosting,  translating,  conversion) 


What  we  are  looking  for  in  reengineering  solutions,  methods  and  tools: 

?  reengineering  process  definition  (hopefully  related  to  ESP  or  GSEP) 

?  methodology  for  analyzing  and  synthesizing  systems  that  contain 
reengineered  legacy  systems,  have  additional  requirements,  and  may  incl^ude 
COTS  software  (in  order  to  satisfy  all  new  requirements) 

?  reengineering  taxonomy  (classification)  and  implementation  of  such 
taxonoity  to  practical  problems  (similar  to  E.  Chikofsky  s  paper  in  IEEE 
Software  ) 

?  development  of  test  strategies  (including  test  case  generation)  for  such 
systems 

?  tools  for  analyzing,  synthesizing  and  then  testing  such  systems  (forward- 
and  re-engineering  tools  integrated  into  one  tool-set  (through  a 
repository?) ) 

?  Project  management  aspects; 

?  estimation 

?  planning  and  scheduling 
?  controlling 

2  quality  assurance  and  configuration  management 

?  Process  engineering  aspects 
?  process  descriptions 

?  life-cycle  selection  (waterfall,  incremental,  evolutionary) 

?  reengineering  risk  analysis  (similar  to  R.  Arnold  s  paper) 

?  Effectiveness 

?  cost/benefit  models  for  each  reengineering  approach  (e.g.  conversion, 
reverse  engineering,  rehosting,  mixture) 

?  when  NOT  to  reengineer? 
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Re-engineering  User  Interfaces:  A  Case  Study 

Anne  Rose 

Human-Computer  Interaction  Laboratory 
Center  for  Automation  Research 
University  of  Maryland 
College  Park,  MD  20742 
rose@cs.umd.edu 
hnp://www.cs.umd.edu/projccis/hcil 


November  29, 1995 


The  Human-Computer  Interaction  Laboratory  ^CIL)  is  currentiy  under  contract  with  the 
Maryland  Department  of  Juveiule  Justice  (DJJ)  to  make  recommendations  for  redesigning  tiie 
user  interface  of  their  information  system,  ISYS.  ISYS,  Information  System  for  Youth  Services, 
is  a  terminal  based  system  used  to  support  the  case  procesjsing  of  approximately  50,000  referrals 
of  delinquent  youth  behavior.  It  is  built  around  a  centralized  IDMS  database  tiiat  is  ruiming  on  an 
IBM  mainframe  located  at  the  Annapolis  Data  Center.  ISYS  is  used  by  about  600  DJJ  employees 
in  various  offices  and  facilities  across  the  state. 

During  our  first  year,  we  evaluated  ISYS,  proposed  short  term  recommendations,  and  developed 
prototype.s  for  NISYS,  the  next  generation  ISYS.  We  employed  several  techniques  to  learn, 
assess,  and  evaluate,  ISYS  including  reading  the  documentation,  performing  22  field  visits, 
attending  training  se.s.sions,  getting  our  own  hands-on  experience,  and  administering  the 
Questionnaire  for  User  Interaction  Satisfaction  (QUIS)  [2]  [6].  QUIS  was  developed  by  the  HCDL 
to  quantitatively  evaluate  the  strengths  and  weaknesses  of  u.ser  interfaces.  Ih  consultation  witii 
DJJ,  the  QUIS  was  tailored  to  addre.ss  .specific  issues  of  concern  to  DJJ  and  administered  to  332 
employees.  The  mean  rating  for  ISYS,  out  of  9,  was  5. 1. 

The  field  visits  provided  us  with  valuable  insight  about  ISYS,  and  about  the  functioning  of  DJJ  in 
general.  A  typical  visit  consisted  of  an  overview  from  a  supervisor,  observing  users  performing 
routine  tasks,  and  discussing  what  they  liked  and  disliked.  We  refined  our  observation  techniques 
and  proposed  an  applied  ethnographic  method  for  redesigning  user  interfaces  [5]. 

Based  on  our  findings,  we  proposed  2S  short  term  recommendations  to  improve  the  ISYS 
interface  while  NISYS  is  being  developed.  Our  recommendations  focused  on: 

•  making  system  access  easier, 

•  improving  data  accuracy, 

•  maldng  information  retrieval  easier, 

•  increasing  the  usefulness  of  the  system,  and 

•  improving  user  satisfaction. 

Wc  provided  a  rough  estimate  of  the  payoff  vs.  the  implementation  cost  for  each  recommeridation. 
DJJ’s  initial  response  was  to  take  action  on  all  28  recommendations.  However,  because  of  internal 
restructuring  only  a  few  recommendations  have  been  implemented  to  date. 
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We  also  proposed  three  NISYS  prototypes  in  response  to  the  needs  discovered  during  the 
evaluation: 

•  LifeLines,  which  uses  time  lines  to  display  a  youth's  history  with  DJJ  on  one  screen  [4], 

•  the  DJJ  Navigator,  which  helps  manage  individual  workloads  by  displaying  different  user 
views,  and 

•  the  Lifotmation  Visualization  &  Exploration  Environment  (TVEE)^ ,  a  generic  tool  that  can  be 
used  to  visualize,  explore,  and  make  queries  on  DJJ  datasets  [1]. 

We  demonstrated  these  prototypes  to  60  DJJ  personnel  and  made  revisions  based  on  then- 
comments.  Overall,  their  feedback  was  very  positive.  One  challenge  we  have  fovmd  is  how  to  get 
constructive  feedback.  For  many  DJJ  employees,  ISYS  is  their  only  computer  experience  so  they 
find  it  difficult  to  provide  con.stnictive  criticism.  They  seem  to  like  our  prototypes  too  quickly 
simply  because  it  looks  better  than  what  they  have  now.  Providing  rou^  .sketches,  that  don’t  look 
like  finished  applications,  or  providing  alternative  designs,  might  be  the  solution. 

We  have  also  been  working  with  Cognetics,  Coip.,  our  subcontractor,  who  Ls  working  in 
conjunction  with  DJJ,  to  prepare  the  reque.st  for  proposal  (REP)  for  NISYS.  The  Cognetics 
De.sign  Methodology  (CDM)  is  being  used  for  this  process  [3].  We  are  currently  working  on  the 
functional  requirements.  The  NISYS  project  is  serving  as  an  exercise  to  test  the  practicality  of 
CDM.  CDM  is  being  modified  as  new  needs  are  discovered. 

REFERENCES 

[1]  Ahlberg,  C.,  Wistrand,  E.,  IVEE:  An  Information  and  Visualization  &  Exploration 
Environment,  Proceedings  of  IEEE  Visualization  '95  (Atlanta,  Georgia,  October  1995),  66- 
73. 

[2]  Chin,  J.,  Diehl,  V.,  and  Norman,  KL,  (1988),  "Development  of  an  instrument  mea.surtng  user 
satisfaction  of  the  human-computer  interface".  Proceedings  cf  CHI’SS — Human  Factors  in 
Computing  Systems,  ACM,  New  Yoric,  213—218. 

(31  Kieitzburg,  C.,  (1995),  “Managing  for  Usability:  The  Cognetics  Design  Methodology”, 
Cognetics,  Corp.,  Princeton  Junction,  NJ. 

[4]  Plaisant,  C.,  Milash,  B.,  Rose,  A.,  Widoff,  S..  Shneiderman,  B.,  (1995),  “LifeLines: 
Visualizing  Personal  Histories”,  to  appear  in  Proceedings  of  CHI  ‘96,  ACM,  NY. 

[5]  Ro.se,  A.,  Shneidennan,  B.,  Plaisant,  C.,  (1995),  “An  Applied  Ethnographic  Method  for 
Redesigning  User  Interfaces”,  Proceedings  ofDIS  ‘95  (Ann  Arbor,  Michigan,  August  1995), 
ACM,  NY,  115-122. 

£6]  Vanniamparampil,  A.,  Shneiderman,  B.,  Plaisant,  C.,  and  Rose,  A.,  (1995),  "User  Interface 
Reengineering:  A  Diagnostic  Approach",  CAR-TR-3459,  University  of  Maryland,  College 
Paric,  MD. 


llVKF-  was  developed  by  Christopher  Ahlberg  and  Erik  Wistrand  of  Chalmers  University,  Sweden.  It  is  based 
on  earlier  research  by  HCIL.  URL:  http://www.cs.chalmers.se/SSKKIWvee.hanl 
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Registration  for  SPC  Reengineering  Wkshp  (fwd)  11/27/95  8:44:59  AM 

Return-Path :  <brewer0medusa . Software . ORG> 

Received:  by  Software.ORG  (/\==/\  Smail3. 1.25.1  #25.19) 
id  <m0tHaeD-0001PHC@Software.ORG>;  Mon,  20  Nov  95  13:08  EST 
Received:  by  medusa.Software.ORG  (/\==/\  Smail3. 1.25.1  #25.10) 
id  <mOtHaeD-OOOOAuC@medusa. Software. 0RG>;  Mon,  20  Nov  95  13:08  EST 
Date:  Mon,  .20  Nov  1995  13:08:52  -0500  (EST) 

From:  Gerry  Brewer  <brewer@Software.ORG> 

Subject:  Registration  for  SPC  Reengineering  Wkshp  (fwd) 

To :  f acemireS  Software . ORG 

Message-ID:  <Pine. 3. 89. 9511201339. H18964-0100000@medusa> 

MIME-Version:  1.0 

Content-Type:  TEXT/PLAIN;  charset=US-ASCII 


-  Forwarded  message  - 

Date:  Mon,  20  Nov  1995  13:00:09  -0500 

From:  Karen  White  <krwhite@smtpgate.read.tasc.com> 

To:  brewer@software.org 

Subject:  Registration  for  SPC  Reengineering  Wkshp 


Name:  Karen  R.J.  White 

Conpany :  TASC 


Address:  55  Walkers  Brook  Drive 

Reading,  MA  01867 


Telephone:  617-942-2000  x.  2654 

FAX  #:  617-942-7100 

E-Mail:  krwhite@tasc.com 

Title:  Project  Leader 


(  )  I  will  be  sending  you  a  position  statement  by  Nov.  30. 

POSITION  STATEMENT  IS  INCLUDED  BELOW. 

(  )  I  am  interested  in  making  a  reengineering  presentation  at 
the  workshop.  My  topic  is  on:  -  , 


POSITION  STATEMENT: 

I  have  been  involved  with  the  enhancement  and  maintenance  of 
so-called  legacy  software  systems  for  the  past  17  years.  During  that 
time  I  have  seen  systems  translated  from  one  language  to  .another, 
re-structured  to  provide  better  performance,  and  coitpletely  re-built. 
Within  the  immediate  past  history,  I  have  participated  in  efforts  that 
ranged  from  the  reengineering/re-hosting  of  a  user  interface  associated 
with  a  legacy  system,  to  the  development  of  a  strategic  plan  for 
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Registration  for  SPC  Reengineering  Wksbp  (fwd)  11/27/95  8:44:59  AM 

reengineering  of  an  application,  to  the  reengineering  of  a  "mission  critical" 
(but  not  embedded!)  system. 

The  problems  we  encountered  were  primarily  associated  with  the 
"reverse  engineering"  activities  and  managing  the  user's  expectations 
about  the  final  product.  The  project  management  (both  customer  &  user) 
held  the  assumption  that  one  can  successfully  reengineer  an  application 
by  analysing  only  the  existing  software,  a  piece  at  a  time.  We  failed  in 
conveying  to  them  the  benefit  associated  with  having  the  current  support 
staff  participate  in  the  reengineering  project.  (It  should  be  noted  that 
support  of  the  legacy  system  was  provided  by  another  contractor  &  that 
they  were  the  users  of  the  new  system;  the  customer  was  a  DoD  dept.) 

A  conprehensive  reverse  engineering  project,  including  development  of 
models  of  the  undocumented  legacy  system,  should  have  been 
coirpleted  before  we  started  the  forward  engineering;  there  would  have 
been  fewer  surprises  at  the  end.  Or,  the  project  should  have  been 
treated  as  a  "scrap  the  old  &  let's  build  a  new  from  scratch"  with  a 
full-blown  requirements  analysis  phase. 

My  interests  are: 

(1)  Approaches  to  reengineering  user  interfaces  INDEPENDENT  of  the 
rest  of  the  application; 

(2)  Connecting  business  process  modelling,  reverse  engineering  and 
forward  engineering.  What  methods  exist  (don't  exist)  that  allows  a 
business  manager  to  see  in  a  straightforward  fashion  how  the  current 
system  does  or  does  not  support  the  business  process  and  how  the 
proposed  system  will. 

(3)  Management  of  a  reengineering  project;  how  does  one  identify  the 
risk  areas,  does  one  break  the  project  up  into  reverse  engineering 
projects  and  then  forward  engineering  projects;  how  does  COTS 
integration  "mess  up"  the  picture;  where  are  the  logical  milestones  for 
"go,  no-go"  decisions 
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UNIVERSITY  OF  MARYLAND  AT  COLLEGE  PARK 


OFFICE  OF  TECHNOLOGY  LIAISON  ♦  GRADUATE  STUDIES  AND  RESEARCH 

QUESTIONNAIRE  FOR  USER  INTERACTION  SATISFACTION 

("QUIS™”) 

The  most  powerful  computer  is  a  computer  which  people  will  use; 
similarly,  software  programs  must  meet  the  approval  of  the  end  user  to  be 
effective.  Measuring  and  understanding  user  reactions  to  computer  software  is 
important  to  many  who  are  creating  new  services  and  programs,  evaluating  older 
versions,  or  making  choices  between  similar  products  for  certain  applications. 
While  the  evaluation  of  a  system's  accuracy  is  fairly  straightforward,  the 
assessment  of  the  user's  satisfaction  with  the  human-computer  interface  is  a 
subjective  and  complex  question. 

A  multi-disciplinary  team  of  researchers  at  the  University  of  Maryland  at 
College  Park  (UMCP)  has  developed  an  instrument  which  evaluates  user 
satisfaction  with  the  human-computer  interface  aspect  of  other  software  packages 
and  computer  systems.  The  Questionnaire  for  User  Interaction  Satisfaction 
("QUIS™")  includes  a  paper  version  as  well  as  a  computerized  questionnaire 
which  assesses  users'  attitudes  and  subjective  satisfaction  with  a  system,  especially 
the  users'  evaluation  of  the  human-computer  interface.  "Although  a  system  may 
be  evaluated  favorably  on  every  performance  measure,  the  new  system  may  not 
be  used  very  much  if  the  user  is  dissatisfied  with  the  system  and  its  interface," 
said  Dr.  Kent  L.  Norman  of  the  UMCP  Department  of  Psychology  and  the 
Human-Computer  Interaction  Laboratory  (HCIL). 

The  QUIS™  covers  four  major  areas:  Screen,  Terminology  and  System 
Information,  Learning,  and  System  Capabilities.  Within  each  area,  several  issues 
are  rated  on  a  nine-point  scale,  with  guides  such  as  Barely  Legible...Very 
Legible;  Confusing...Clear;  Difficult...Easy;  Complex...Simple.  The  wide  range 
of  topics  includes  the  computer's  noise  level,  helpfulness  of  reference  materials, 
even  screen  sequencing.  The  user  is  able  to  rate  any  computer  program  using 
QUIS™,  thus  producing  a  reliable  evaluation  of  the  interactive  workstation. 
According  to  Dr.  Benjamin  Shneiderman  of  the  Computer  Science  Department 
and  Director  of  the  HCIL,  "The  QUIS™  does  two  things.  It  taps  the  overall 
subjective  reaction  of  a  user  to  an  on-line  computer  system,  and  it  is  a  diagnostic 
of  die  strengths  and  weaknesses  of  a  system.  It  assesses  such  things  as  satisfaction 
with  the  display  of  graphics,  readability,  reliability,  understandability,  and  other 
features."  Please  see  reverse  for  additional  specifications. 


4312  KNOX  ROAD  ♦  COLLEGE  PARK,  MARYLAND  20742  ♦  (301)405-4209  *  FAX;  (301)  314-9871 
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The  QUIS™: 

Questionnaire  for  User  Interaction  Satisfaction 

Developed  in  the  Human/Computer  Interaction  Laboratory  at  the  University  of  Maryland  by  Kent 
Norman  and  Ben  Shneiderman,  the  QUIS™  is  one  of  the  only  instruments  for  assessing  user 
evaluations  of  interactive  workstations  that  has  proven  reliability  and  validity.  It  has  been 
standardized  ovCT  a  number  of  applications  and  research  studies.  It  is  now  being  used  in  the  field 
by  a  number  of  usability  and  research  labs  in  both  government  and  industry. 

The  QUIS™  assesses  6  factors  of  overall  reactions  to  the  system  and  21  components  that 
contribute  to  usability.  The  QUIS™  can  be  used  in  its  current  form  or  modified  to  meet  particular 
research  needs. 


The  QUIS™  is  available  in  a  paper  version  and  two  on-line  versions  (a  Windows™  version  and  a 
Macintosh™  Spinnaker  Plus™  version). 


QUIS™  Site  License  Information 

A  site  license  for  commercial  use  of  the  QUIS™  is  now  available  for  $750.  A  reduced  fee  ($200) 
is  available  for  academic/non-profit  use.  The  licensing  package  includes  the  following: 

•  Two  copies  of  the  QUIS™  paper  version  with  the  right  to  make  an 
unlimit^  number  of  copies  for  use  at  one  site. 

•  Copies  of  all  HCIL  publications  pertaining  to  the  use  of  the 
QUIS™. 

•  The  Windows™  version  of  the  QUIS™  on  a  3.5  inch  floppy  disk 
with  the  right  to  use  copies  at  your  site. 

•  The  Macintosh™  Spinnaker  Plus™  stackware  version  of  the 
QUIS™  on  a  3.5  inch  disk  with  the  right  to  use  copies  at  your  site. 

•  Run-time  versions  of  Macintosh  Spinnaker  Plus. 


The  site  license  gives  authorization  for  unlimited  use  of  the  QUIS™  at  one  site.  You  may  copy  the 
entirety  of  the  questionnaire,  parts  of  it,  or  revise  it  for  use  in  evaluation  of  commercial 
software/hardware  for  usability  testing,  research,  and  development 


For  technical  information  on  the 
QUIS™,  contact: 

Dr.  Kent  L.  Norman 
Department  of  Psychology 
University  of  Maryland 
College  Park,  MD  20904 
(301)405-5924 


To  receive  the  licensing  package, 
contact: 

Ms.  Carolyn  A.  Garrett 
Office  of  Technology  Liaison 
4312  Knox  Road 
University  of  Maryland 
College  Park,  MD  20742 
(301)  405-4210 
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Systems  Reengineering 
Position  Paper 
for 

Second  SPC  Reengineering  Workshop 
Mark  L  Wiison 

Naval  Surface  Warfare  Center  ODANO 
mlwilsoOrelay.nswc.navy.mlf 
301-394-5099 

We.  in  the  Navy  tactical  community,  are  concerned  primanly  with  real-time,  safety  critical, 
mission  critical,  complex  systems.  Many  of  these  systems  are  written  in  CMS-2  programming 
language  wth  at  least  some  and  often  substantial  amounts  of  assembly  code.  They  run  on  Navy 
military  standard  computers  such  as  UYK-7,  UYK-43,  UYK-20.  UYK-44,  and  AYK-14. 

Most  of  these  systems  were  designed  with  memory  or  other  architectural  constraints 
which  no  longer  apply.  Thus  thorough  reengineering  requires  consideration  of  the  design 
rationale  which  may  not  be  explicit  in  the  existing  documentation.  Moreover,  there  may  be  tinting 
or  other  relationships  which  only  become  apparent  during  the  most  thorough  system  test 

Driving  factors  for  reengineering  may  include  a  desire  to:  avoid  hardware  obsolescence, 
increase  performance  to  accommodate  new  or  enhanced  requirements,  reduce  software 
maintenance  costs,  reduce  hardware  procurement  costs,  reduce  maintenance  costs,  and  take 
advantage  of  current  software  design  practices  and  tools.  In  essence  the  goal  is  rehosting  or 
retargeting  to  improve  performance,  reduce  cost,  and  reduce  development  time.  A  secondary 
goal  is  to  try,  where  practical,  to  further  reduce  cost  and  development  time  through  reuse. 

One  of  our  short  term  goals  is  the  ability  to  efficientiy  transform  highly  hardware 
dependent  legacy  systems  into  moderately  hardware  independent  open  systems.  Our  long  term 
goal  is  the  ability  to  effectively  transform  complex  legacy  ^sterns  into  systems  that  can  evolve 
gracefully  over  time.  Evolution  will  typically  involve  increased  requirements,  new  processor 
hardware,  new  display  technologies,  and  integration  with  additional  systems.  It  may  also  involve 
reuse  within  or  across  systems  and  domains,  totally  new  requirements  unanticipated  during 
design,  partition  into  parallel  or  distributed  architectures,  combination  into  fewer  more  powerful 
processors,  new  human  computer  interfaces,  networks  to  replace  point-to-point  communication, 
or  translation  from  one  language  into  another. 

Some  of  the  techniques  we  see  as  useful  are  a  layered  approach  to  system  and  software 
design,  automatic  or  semiautomatic  language  translation,  and  graphical  aids  to  software  and 
^tem  understanding.  It  may  also  be  useful  to  have  econometric  models  to  guide  the  decisions 
of  vriien  and  how  to  reengineer. 

We  at  NSWC  have  addressed  a  number  of  these  issues.  Among  them  we  have  helped 
develop  and  test  CMS-2  to  Ada  translation  tools,  an  Assembler  to  CMS-2  translator,  graphical 
aids  to  software  understanding,  and  have  worked  on  populating  several  domains  with  legacy 
components.  Most  of  this  work  was  funded  by  ONR,  some  by  SBIRs,  and  some  by  the 
JLC/CRM/RRFWG.  We  also  organized  and  sponsored  a  series  of  Systems  Reengineering 
Technology  Workshops  •  the  last  two  of  which  were  held  in  Monterey,  California;  and  a 
Reengineering  Focus  Group  at  the  First  and  Second  Workshop  on  Engineering  Systems  in  the 
Twenty-First  Century  (WES21). 
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3.  SLIDES  PRESENTED 


This  section  contains  copies  of  the  slides  used  in  presentations  at  the  workshop.  The  slides  are  arranged  in 
chronological  order  (see  Appendix  B). 
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Jeff  Facemire 
703-742-7189 


facemire@software.org 

http://www.software.org 


SCFTltMfF 

franucTMTY 

CONSORIMM 


Product  Lines 


Product  Lines  -  A  collection  of  (existing  and 
potential)  products  that  address  a  business 
area 

Recently  mandated  by  Lloyd  Mosemann 
(SAF/AQK)  for  the  Air  Force  to  do  Domain 
Engineering  to  product  lines 

Mosemann  sited  SPC’s  product  line  approach 
as  implemented  in  the  Navy/STARS  program 

Other  examples  sited:  PRISM  and  CARDS 


SOnWAWF 
W  PfVDLMTTMJy 
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•  A  poor  fit  (actual  or  apparent)  Increases  risk/cost  of: 

-  Recognizing  - 

the  opportunity  fit  in  new  system 

—  Finding  asset  to  reuse  _  worifvina  fit  in  new  systen 


Verifying  fit  in  new  system 


Variation  among  projects  threatens  a  good  fit. 


c<vyrtfM  e  im.  so«w«r  rHte«>«y  cm 


SOFTWAnF 

fmxJCTMTY 

.^JSi^^y'.ssss'  coNSORnw 


•  Legitimate  variations  arise  from  different  customer  needs. 

•  Incidental  variations  arise  in  project  management  or 
technical  approach  and  viewpoint. 

•  Legitimate  and  incidental  variations  interact  to  create 
complex  variations  among  similar  projects. 


SOFTWARE 

- /jaggy  RwaaurTvrjY 

,^^s^.vjssar  ansomxM 
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Relationship  to  Reengineering 


•  SPC’s  product  line  approach  has  been 
performing  many  aspects  of  conventional 
reengineering  (organizational,  process  and 
product  improvement) 

•  Reverse  engineering  can  help  to: 

-  Determine  commonalities  and  abstraction 
in  legacy  code 


-Capitalize  on  existing  assets  for  use  in  the 
product  line 

•  Product  line  engineering  with  or  for 
reengineering  will  likely  use  both  top-down 
and  bottom-up  analysis 


_ _ 

AIlr^MinMnwiL 


SOFTWARE 
PFDOUCrMTY 
CONSORTIUM 


Adoption  Process 


Product 


Organization  Environment 


V _ 
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Result  of  Domain  Engineering 


•Application  production  is  mechanical  and,  possibly,  automated 


Product  Line  Engineering 


•  Engineering  product/component  families  and 
an  associated  production  process  to  optimize 
support  for  a  defined  business  area. 

•  Concern  with  reuse  focused  on  given 
organization’s  business  area 

•  Addressing  variabilities  via  adaptability  of 
product/components  (including  requirements, 
architecture,  tests,  etc.) 

•  Borrows/integrates  other  reuse  technologies 

•  Examples:  Consortium's  Synthesis,  GCSS/ 
CASS,  NSWC/RNTDS,  Toshiba 


soFmwy 
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Business  and  Technology 
Trends 


•  Business  Trends: 

-  Changing  government  roie 

-  Cost  reduction 

-  Cycle-time  reduction 
(time-to-market  improvement) 

-  Incremental  product  changes 

-  information  explosion 

-  Market  globalization 

-  Rapid  market  changes 


Technology  Trends: 

—  Architecture-based  composition  of 
systems  (application  generation) 

—  Business  process  reengineering  and 
engineering  process  improvement 

—  Distributed  development 

— ’  Distributed  systems  (client/server) 

— >  Integrated  product  and  process 
development  (multifunction  teams) 

—  Multimedia 

—  Object-oriented  development 
Software-intensive  systems 


V _ : _ 
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Mainframe  to  Geographically 
Distributed  Client/Server 
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A  Much  More  Versatile  But 
Complex  Physical  Infrastructure 
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Reengineering  of 
Information  Systems 


Embedded 

System 


Legacy 

IS/System 


Potential 

Reengineering 

Activities 


Domain 

Analysis 


Portfolio 

Analysis 


New 

Requirements 


Family  of 
Systems 
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SPC’s  Product  Line  Approach 


Business 


Domain 

Knowledge' 


Customer 

Requirements 


Process 


(Reuse-Driven) 
JSystem/Software 
Development 
Process 


'Application 
V  System  J 


lApplication  Use 
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MYTHS  AND  REALITIES 

Defining  Re-engineering  for  a 

l\ 

Large  Organization 

iii 

i 

li! 

Sandra  Yin  (ISM:TM:S) 

V 

!l 

Julia  McCreary  (ISD:I:SE) 

Internal  Revenue  Service 

•■il' 

I 

1111  Constitution  Ave. 

I 

•t'  I 

1 ;  I 

Washington,  D.  C.  20224 

U*  1 

•  '  o  ■  c.  ■  , 

li  1’ 

j  1 

Myths  of 

Reverse  and  Re-engineering  are  synonymous 
Re-engineering  soils  pure  top-down  effort 
Old  programs  -  nothing  to  salvage 
Re-engineering  is  fully  automated 
Single  CASE  tool  -  solution  for  new  development 
Buy  a  CASE  tool - 

-  Infrastructure  not  essential 

-  Work  process  -  no  need  to  examine 

-  Organizational  readiness  will  just  happen 

-  Process  improvement  is  peripheral 
Wishful  thinking  makes  it  so 
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Realities  of 

Establish  Clear  Objectives 
No  Silver  Bullet 

Embrace  Business  Re-engineering  Early 
Get  Experienced  Guidance 
Phased  Change 
Balance  R&D  with  short  term  Return-on-Investment 
Gather  Case  Study  Results 
Transition  is  a  major  issue 


Transition 

•  Cross  References  from  Old  to  New  Data  and 
Processes 

Conversion  Routines 
Synchronize  Change  Control 


Architectuie  Transition  Management  -  Functional  Transition 


Legacy  Architeotuie 


Target  Client/Sc^er 
Aichiteobue 
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Looking  for  Realities 

:4.  ' 

’  ‘.Establish  objectives 
Identify  opportunities 
identify  tools  and  method 
Support  transition  strategy 
Target  implementation 
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Recommended  Future  Strategies 

•  Potential  Benefits  of 

•  Develop  Plan  for  IRS 

•  Define  Criteria  for  IRS 

•  Evaluate  the  R^  Market 

•  Prototype  Projects  in  ISM 

•  Technology  Transfer 
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Outline 


3.  Slides  Presented 


•  •  o 

OO 

CO  W) 

W  S 

O  c 
o^ti: 


bo  CQ 


c 

<D 

C 

^  S- 

^  o  , 

CO  ^ 
t-J  ^  I 

2  « 

o  wi 


OiS 

3  S 
s  « 

[Tf 

pq  ^ 


'^2^0 

CO  3  ^ 
O  CO 

g|> 
8|  8 
U<  PQ 

I  c  I 


CO  ^ 
>  ^ 


CO  I 

SH 

CO  O 

>%  CO 

CO  -g 
CX)  o 

c  c 


I  r-^ 

U  H 

>  <D 

<  7^ 

Iz;  S 


.t=  >> 
cd  o 


W  S  S, 
P-i  S  ^ 

w 


j  s 

O  ^ 

^  W) 

PQ  S 

Os::  4- 
<D 


CO  G 

c  ^ 

2^  G 
G  0) 

o  c 
CU  o 

G  04 

R  S 

O  o 

T3  ^ 
0) 

O  ^ 
<D  o 

CO  Q 

W  CO 
CO  ^ 

r(D  .GJ 
P^-i 


3-20 


Augmented  Methodology  Process  and  Steps 
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Nodes  and  Edges  in  SRE  Analyzed  Legacy  Code  Repository 
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PCB__Pkg  Scope  Graph 
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Producer_Consumer  Unit  Map 
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PCB_Pkg  Message  Relations 
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PCB_Pkg  Interface  Report 


/* - - - - 

INTERFACE  REPORT  for  pcbjpkg  (1.2) 

. . . . - . - . . . . 

EXTERNAXi  INTERNAL 


CALL: 

1:  {PROCEDURE  enco<ie_inessage  (  data  :  IN  integer  ;  msg  ;  OUT  message  }  ;  ]  (1.1) 
< — -  {encode^jnessage  (  in_data  ,  msg  )  ;  1 
2:  {FUNCTION  decode_message  (  msg  :  IN  message  )  RETURN  integer  ;  ]  (1.1) 

< - [out_data  :*  decode_message  (itisg)  ;  ] 


MEMORY: 

3:  [PROCEDURE  encode_message  (  data  :  IN  integer  ;  msg  :  OUT  message  )  ;  ]  (1.1) 

- >  [encode_message  {  in_data  ,  msg  )  ;  ] 

4:  [PROCEDURE  encode_message  (  data  ;  IN  integer  ;  msg  ;  OUT  message  )  ;  ]  (1.1) 
< — -  [€ncode_message  (  in^data  ,  msg  )  ;  ] 

5:  [FUNCTION  dec ode_mes sage  (  msg  :  IN  message  )  RETURN  integer  ;  ]  (1.1) 

< - [out^data  decode_mes sage  (msg)  ;  ] 

S:  [FUNCTION  dec ode^mes sage  (  msg  :  IN  message  )  RETURN  integer  ;  3  (1.1) 

- >  {out_data  :=  decode_mes sage (msg)  ;  3 


TYPE: 

7:  [TYPE  message  IS  ]  (1.1) 

< — -  [msg  :  message  ;  3 
8:  [TYPE  message  IS  ]  (1.1) 

<  -  [msg  :  message  ;  ] 

9:  (TYPE  message  IS  J  (1.1) 

<  -  [ACCEPT  read  (  data  :  OUT  message  )  DO  ] 

10:  [TYPE  message  IS  3  (1.1) 

<- —  [ACCEPT  write  (  data  :  IN  message  )  DO  3 
11:  [TYPE  message  IS  3  (1.1) 

<  -  [contents  :  message  ;  ) 

12:  [TYPE  message  IS  }  (1.1) 

<  -  [ENTRY  write  (  data  :  IN  message  )  ;  ) 

13:  [TYPE  message  IS  3  (1.1) 

<  -  [ENTRY  read  (  data  :  OUT  message  )  ;  J 


CONTEXT: 

14:  (TASK  BODY  buffer  IS  )  (1.4.1) 

<-—  (TASK  buffer  IS  3 

15:  [ACCEPT  read  (  data  :  OUT  message  )  DO  ]  (1.4.1) 

<  - (ENTRY  read  (  data  :  OUT  message  )  ;  ) 

16:  (ACCEPT  write  (  data  :  IN  message  )  DO  ]  (1.4.1) 

<  -  [ENTRY  write  (  data  :  IN  message  )  ;  3 

17;  [TASK  BODY  producer  IS  ]  (1.4.2) 

<  -  [TASK  producer  IS  j 


18: 

(ACCEPT  p_init  {  filename 

:  IN  string  ) 

DO  3 

(1.4.2) 

<-—  [ENTRY  p.init  ( 

filenaune  :  IN 

string  ) 

;  3 

19: 

(TASK  BODY  consumer  IS  3 

(1.4.3) 

<---  [TASK  consumer 

IS  3 

20; 

[ACCEPT  c^init  {  filename 

:  IN  string  ) 

DO  3 

(1.4.3) 

< -  (ENTRY  c_init  ( 

filename  :  IN 

string  ) 

;  1 

21: 

[PACKAGE  BODY  pcb_p)cg  IS 

3  (1.4) 

<—  (PACKAGE  pcb_p)cg  IS  ] 
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Producer  (1.4.2)  Scope  Graph 
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Process  Steps  for  Fusion  AVTS  Domain  with  Propulsion  Components 

of  Trainers  of  T-34  and  T-44  Legacy  Code 
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Transforming  Software  Architecture  Requirements:  Adapting  Reuse  Candidate 
Legacy  Architectural  Components  for  Inclusion  in  a  Domain  Architecture 
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Re-Engineering  User  Interfaces  for  the 
Maryland  Department  of  Juvenile  Justice 


Anne  Rose 

Human-Computer  Interaction  Laboratory 
University  of  Maryland 
College  Park,  MD  20742 
rose@cs.umd.edu 


December  4, 1995 


IlCjil]^  Our  Goal 


To  make  recommendations  for  developing 
an  information  system  that  effectively  meets 
the  needs  of  DJJ,  with  an  emphasis  on  the 
user  interface  design 
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Sample  ISYS  Screen 


la 

BHi 

1  OODX1C03 

XSZS  -  ZHFOmATIOM  SXSTQf  FOR  EOUTH  SERVICES 

10/37/94  15:04 

1  lEQCASE 

CASE  DETAIL  IDQlflRT 

1IJ1M03 

DOUTK  aiMBCR:  OOOIMIM  CASE  K>:  02/14/93  >  01 

■MiB:nisT  mill  MID  xxmxx  lst  xjuuu  sur 

dob:  zx/zx/xx  VBRiFizixy/x)  t  H  RMCX:  X  SBXt  z  Gommii  24 

-  COSE  - - 

KBCBIVED:  DATE  02/14/93  SOURCE  POLC  SEASOE  OSLO  OFFICE  71610 

IHTIUIZ  BBCISKEI:  DOTE  02/14/93  OGEE  CCOI  J10BECZ  >BF  TO 


APPBMJED:  /  / 


AFFEM.  DXSP  CODE:  APFEM.  DISF  DATE:  /  / 

JUDGE/MOSTDl: 

DXSP  mni  /  /  DXSP  CCOB: 


COURT  riXDXEO:  DXSP  DRTI:  /  /  DXSP  CCOB: 

TESM/COMD:  WKE 

TEOMIXATXOBt  FIXED  /  /  ACTUM.  02/19/91  LAST  UPDTt  01/07/93  TEXT:  ■ 

COBSEXT  OXVZE(T/V>;  START  DATE:  /  /.  EXPDT  DATE:  /  /  - 

ALtB(«D  OFFEXSE:  01  DATE  02/14/93  CODE  Xm  CTZ  16  POL  CMFUR  «0:  93045011 
OBSC/CFP  EAR  AHAX  FRCII  MCM  UPOV  RELEASE  FRCM  CSC  ARREST  DATE  02/14/93 
XX)CATX<XI  STREETS  OP  OXSB  HILL  M.D.  ZIP  20749  0000  OTH  IEV<X/E)  X 

POLICE  ID  1777  POLICE  »IIB  HICODBIUS 

ADOUDIC  OPPEESEt  00  CODE  PBTI  DISP  CODE  DATE  /  / 


MEET  REQUEST:  HQCASE  XEZT  KEX: 
DO  aORB  DATA 
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Benefits  of  Ethnographic  Evaluation 


•  learned  how  system  was  really  being  used 

•  humanized  user  problems 

•  increased  trustworttiiness  and  credibility 

•  users  became  increasingly  active  participants  in  the 
design  process 


Questionnaire  for  User  Interaction 
Satisfaction  (QUIS) 


•  developed  by  HCIL,  proven  reliability  and  validity 

•  customized  to  assess  ISYS 

•  administered  to  332  DJJ  personnel 
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Improving  the  Login  Procedure 


ISYS  Loein  Procedure: 

Sueeested  Procedure: 

Type: 

BDCDEV 

Type: 

login  id 

Press: 

Oear  key 

Type: 

password 

Type: 

CSSN 

Type: 

login  id 

Type: 

password  1 

Type: 

DBDC 

Type: 

login  id 

Type: 

passioord  2 

Select: 

ENTC  menu  option 

Type; 

WIM 

Type: 

office  code 

Prototypes 


•  address  needs  discovered  during  evaluation 

•  possible  add-ons  to  existing  system 

•  3  prototypes 

-  DJJ  Navigator  (help  manage  workload) 

“  LifeLines  (present  youth  record  in  single  screen) 

-  IVEE  (visualize  aggregate  information  and  explore  trends) 
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LifeLines  Overview 


•  Single  screen  overview  of  all  cases,  placements, 
assignments  and  reviews  associated  with  a  youti\ 

•  Direct  access  to  frequently  used  ISYS  screens 

•  Zoom  on  smaller  time  period 

•  Highlight  relationships 

•  Potential  add-on  to  current  ISYS  for  PC  users 

•  "life-line"  addresses  the  generic  problem  of  providing 
overview  of  a  person's  life  (e.g.  medical  record,  resume) 


Simple  Youth  Record 


Vguth 


oal 


STM  10194  HIM  1>9«  U9S  218$  HiS  4lfS  yu  tIK  ItfS 
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IVEE  Overview 


•  Inforination  Visualization  &  Exploration  Environment  (TVEE) 

•  Research  tool  being  developed  by  Chris  Ahlberg  and  Erik 
Wistrand  of  Chalmers  University,  Sweden 

•  Dynamic  exploration  of  data  trends  using  zooming  and 
filtering 

•  Supports  generic  datasets 

•  Possible  export  of  subsets  to  other  applications 


llciE  July  1994  Intake  Cases 


<  J  »lin; 

v.k;. 
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Influence  of  Two  Parent  Families 
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Current  Status 


r 


Working  with  Cognetics  Corp.  to  prepare  RFP 
Testing  Cognetics  Design  Methodology  (CDM) 
Report  generation  review 
Soon  will  work  on  overall  prototype 


3.  Slides  Presented 


3-55 


3.  Slides  Presented 


3-57 


3.  Slides  Presented 


3-58 


3.  Slides  Presented 


llllll 


/.8li 

r..  I 

I  fill  il 
I  is  8  8  §  I. 


o 

^  I 

o  JS 

1  ?  8 

2  o  3 

S  o  o  > 

I 

3  E  3  2  ® 

.  s  I  ?  o  I 

V  »  -S  i  8 

-4  ®  i  I  =  I 

71  2  1 1  I 

/ illil 

.E  .£  -E  I  g 

13  -g  1  I  -g 
."o  "2  ?  S  *2 

S  S  §  2  S 
a  a  fo  a  a 

c 

•2  c 

«  .0 

S  3 

ji  ^  :=  Jr  S  .W 
Q  *=  iS  -S  2  ^ 

^  J5  ®  w  £  ® 
I  O  Q  O  CL  S 


1  ItlJ 

I  8  B  8  8  M  S. 

6 . 


o 

1  S  S’  1 

a  ®  o  E  ^ 

E  I  i  S  ^ 

3r  o  Sz  o*  ® 

«  .i  =  2  .i 

|i-ou.l- 
P  ♦  ♦  ♦  ♦ 


CO 
CDv 
^  C  CD 

|:§> 


O  o  S 

*c  ^  w 
•-  o  © 

U>  CLSZ 

PI 

i  ^  ® 

O  ©  :b 


k.  ^ 
<D  3  *£ 
^ 

m  ® 

-c  2  w 

if  ~ 

o-S^ 

fc  M  ♦- 

I'll 

ill 

«£  s 
€0  .  (0 
2r  •  w 

C  CO  0 
©  0  £1 
>  >t  3 

S  00 

.CO  ® 

«  05 

ell 

^la 

^  ra  « 

CM  Jjj 

T3  55  c 

C  jf  O) 

•E  ■£  g 

8  11 


*  «.i  S 

a  S  £  o 
£  o  o  ^ 

®  ^  » 

S' if  2  c 
g  1  25 

■s  $  3  O 
S  Zo  v> 

"*  -Q  m  « 

8-5  .  e 

Hit 

l|gi 

TJ  o  S  '2 

■§■8^  S 

2  S  «5 

a  2  <0 
O  <0  o 

i  >  -c » . 

■asps 
§1  S|  t 

•3*  O  O. 


Jrlf 

ilili 


illlll 


CO 

2 

±-  C3 


^  a 


/  i  8  i 

llllld 


I  . 

ii§ 

E  g  S 

lIS 


3-60 


Wmchester  House  (example)  ^iWipchester  House  (example) 
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d©XtGrity  Identify  the  gaps 

♦  Solving  problems  such  as  removing  4  How  do  will  you  get  there? 

barriers  to  interoperability  Develop  solutions  to  close  the  gaps  and 

Implement 
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♦  What  are  the  relationships  between  each 
object  and  other  objects? 

♦  What  is  the  relationship  between  the  objects 
and  the  processes  which  transform  them? 

[PRES,  1992,  p.  220] 
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Operational 
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SOFTWAHE 


PLC^B^SRAH) 


Report  to  the 

2nd  SPC  Reengineering  Workshop 


Robert  E.  Johnson,  Jr. 

Joint  Logistics  Commanders/ 
Computer  Resources 
Management  (JLC/CRM), 
SAM/AES  Strategic  C4  Plans 
Pentagon 
(703)697-5397 

John  Clark 

Comptek  Federal  Systems,  Inc 
Va  Beach,  Va. 

(804)463-8500 


December  4-5, 1995 


2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

INTRODUCTION 

•  TO  INTRODUCE  JLC-HDBK-SRAH,  VERSION  2.0,  MARCH  1995 

-  A  QUICK  METHOD  TO  DETERMINE  IF  REENGINEERING  IS 
NEEDED  AND  COST  EFFECTIVE 


•  THREE  SEQUENTIAL  PROCESSES: 

-  TECHNICAL  ASSESSMENT:  EVALUAIE  SOFTWARE 
CANDIDATES  AND  SELECT  REENGINEERING  STRATEGIES 

-  ECONOMIC  ASSESSMENT:  CALCULATE  ECONOMIC 
INDICATORS  FOR  EACH  STRATEGY  OF  EACH  CANDIDATE 

-  MANAGEMENT  DECISION:  EVALUATE,  SELECT,  AND 
PRIORITIZE  CANDIDATES  AND  THEIR  STRATEGIES 
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JLC-HDBK-SRAH 


TECHNICAL  REPORT 
Software  Reengineering 
Assessment  Handbook 

Version  2.0 
Volumes  I  and  II 


2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

JLC-HDBK-SRAH  BACKGROUND 

JLC-JPCG-CRM  WORKING  GROUP  AT  SB-1,  TRI-SERVICE 

VERSION  1.0  BY  COMPTEK/MCR 

-  UNDER  COGNIZANCE  OF: 

•  AIR  FORCE  COST  ANALYSIS  AGENCY 

•  SOFTWARE  TECHNOLOGY  SUPPORT  CENTER,  HILL  AFB 

-  TECHNICAL  PARTICIPATION  BY: 

•  AIR  FORCE  STANDARD  SYSTEMS  CENTER.  GUNTER  AFB 

•  COST  MODEL  DEVELOPERS 

-  FOUR  FIELD  TESTS  CONDUCTED 

-  RELEASED  FOR  BROAD  COMMUNITY  REVIEW  FEB  94 

VERSION  2.0  BY  COMPTEK/SAIC/STSC 

-  70  SETS  OF  COMMENTS  INCORPORATED 

-  RELEASED  APRIL  95  AT  STC  ON  THE  CD  ROM 

-  NOW  A  JLC-JPCG-CRM  PRODUCT 
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2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

APPLICABILITY 

•  DOMAIN: 

-  VARIETY  OF  SOFTWARE  (AIS  AND  TACHCAL/REAL-TIME) 

-  VARIOUS  LEVELS  OF  AN  ORGANIZATION 

-  DoD,  NON-DoD,  COMMERCIAL,  INDUSTRIAL.  ACADEMIC 

-  MAINTENANCE,  REUSE,  COTS/NDI  IN  NEW/EXISTING  SYSTEMS 

•  CASES: 

-  1:  A  SPECIFIC  CANDIDATE  WITH  A  SINGLE  STRATEGY 

-  2:  A  SPECmC  CANDIDATE  WITH  MULTIPLE  STRATEGIES 

-  3:  A  SET  OF  CANDIDATES  EACH  WITH  MULTIPLE  STRATEGIES 

•  CHOICES: 

-  MAINTAIN  STATUS  QUO 

-  REENGINEER 

-  RETIRE 


2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

STRATEGIES 

•  STATUS  QUO  (ALWAYS  STRATEGY  1) 

•  REVERSE  ENGINEERING 

•  RESTRUCTURING 

•  TRANSLATION 

•  DATA  REENGINEERING 

•  REDOCUMENTATION 

•  FORWARD  ENGINEERING 

•  RETARGETING 

•  REDEVELOPMENT 

•  ARCHITECTURE  TRANSFORMATION 
(UNDER  CONSIDERATION) 
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OVERALL  PROCESS 


2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

TECHNICAL  ASSESSMENT  PROCESS 
(STRATEGY  SELECTION) 

Purpose;  To  match  legacy  software  components  with  reengineering 
strategies. 

Gives  a  rough  idea  of  where  reengineering  can  help  maintenance 
activities  for  those  organizations  unaware  of  reengineering  principles. 
Based  on: 

-  JLS’s  Santa  Barbara  - 1  Reengineering  Workshop  (Sept.  1992) 

-  US AF  organization  interviews 

-  Fiels  tests  of  SRAH  version  1.0 

•  Gunter  AFB.AL 

•  Wright-Patterson  AFB,  OH 

•  Lawrence  Livermore  Labs,  CA 

•  HillAFB.UT 

-  Initial  reengineering  survey  results 

-  Other  reengineering  projects  data 
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STRATEGY  SELECTION  (cont.) 

•  Reengineering  Projects  Data  Repository 

-  SRAH  validation,  modification,  and  enhancement 

-  Will  help  with  version  3.0  issues  of 

•  “Weighting”  of  questions 

•  Software  size  issues 

-  Pre  and  Post  Surveys  with  Instruction  Set 

•  6  Reengineering  Strategies 

-  Redocument 

-  Reverse  Engineer 

-  Translate  Source  Code 

-  Data  Reengineer 

-  Restructure 

-  Retarget 

•  2  Classical  Maintenance  Strategies 

-  Redevelopment 

-  Status  Quo 
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STRATEGY  SELECTION  (cont.) 

•  Step  1:  Assess  Preparedness  (Question  Set) 

•  Step  2:  Identify  Software  Candidates 

-  Consider  factors  of  age,  complexity,  language,  reliability,  HW/SW 
coupling,  platform  changes,  etc. 

•  Step  3:  Reduce  List  of  Software  Candidates 

-  Suggest  remove  from  list  if: 

•  Remaining  life  <  3  years 

•  Not  important  enough  (Importance  question  set) 

•  Age  <5  years 

•  Software  directly  supports  ongoing  BPR  efforts 

•  Step  4:  Complete  Strategy  Selection  Question  Sets 

-  Redocument 

-  Restructure 

-  Translate  Source  Code 

-  Data  Reengineer 

-  Retarget 
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STRATEGY  SELECTION  (cont.) 

Step  5:  Consider  Other  Maintenance  Strategies 

-  Reverse  Engineer  if: 

*  Multiple  reengineering  strategies  are  indicated 

•  Highly  complex  control  flow 

•  Reuse  is  a  key  objective 

-  Redevelopment  if: 

•  3  or  more  reengineering  strategies  indicated 

*  Remaining  life  >5  years 

-  Status  Quo  if: 

*  No  reengineering  strategies  are  indivcated 
Maintenance  Environment  Considerations  (Question  Set) 

Misc.  Other  Issues 

-  Impotrance  of  Pilot  Project 

-  Impact  Analysis 

-  Pitfalls  of  Source  Code  Translation  and  Restructuring 

-  Software  Analysis  Tools 
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ECONOMIC  ASSESSMENT  PROCESS 
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ECONOMIC  TERMINOLOGY 

•  BENEFIT  (QUANTIFIABLE  AND  NON-QUANTIFIABLE) 

•  BENEFIT  INVESTMENT  RATIO  (BIR):  2ND  BEST  INDICATOR 

•  BREAK-EVEN  POINT  (BP) 

•  COST  SAVINGS  AND  COST  AVOIDANCE 

•  CONSTANT  DOLLARS 

•  CURRENT  DOLLARS 

•  DISCOUNTED  DOLLARS 

•  INVESTMENT  COST  AND  O&S  COST 

•  NET  VALUE  (NV) 

•  PRESENT  VALUE  (PV) 

•  NET  PRESENT  VALUE  (NPV);  BEST  INDICATOR 

•  RATE  OF  RETURN  (ROR) 

•  SUNK  COST 

•  UNIFORM  ANNUAL  COST 
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NET  VALUE  AND  BIR 


NET  VALUE  -  BENEFIT  -  INVESTMENT 
=  O&Sl  -  O&Sn  -  INVESTMENT 
>0:  POSITIVE  RETURN 
<0:NEGATIVERETURN 
-0;  BREAK-EVEN 


BIR  =  BENEHT  /  INVESTMENT 
=  (O&Sl  -  O&SN)  /  INVESTMENT 
>  1 :  POSITIVE  RETURN 
<  I :  NEGATIVE  RETURN 
=  1 :  BREAK-EVEN 
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NET  PRESENT  VALUE  AND  BIR 


NET  PRESENT  VALUE  =  PV  (BENEFIT)  -  PV  (INVESTMENT) 

=  PV  (O&Si)  .  PV  (O&Sn)  -  PV  (INVESTMENT) 
BENEFIT  INVESTMENT  RATIO  =  PV  (BENEFIT)  /  PV  (INVESTMENT) 
-  (PV  (O&Si)  -  PV  (O&SN))  /  PV  (INVESTMENT) 
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STRATEGY  SELECTION 


WHICH  STRATEGY  IS  BEST:  1, 2  OR  3  ? 
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TOTAL  COST  AND  BP 


This  page  intentionally  left  blank. 
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SIMPLIFIED  EXAMPLE 
(no  discounting  or  inflation) 


Yer 

Qfitcf 

5igftKQn 

Cbrtrf 

Hestnat 

1 

NA 

100 

NA 

QfiS 

1 

150 

150 

0 

‘  CSS 

2 

130 

KX) 

SO 

CS& 

3 

ISO 

KX) 

SO 

QfiS 

4 

ISO 

KX) 

SO 

Ted 

600 

550 

130 

NV  =  150 . 100  =  50  or  600  -  550  =  50,  BIR  =  150  / 100  =  1 .5 
BP  =  Year  3  when  cumulative  benefit  =  investment  =  100 


ROR  =  i  =  0.234  or  23.4  %  when: 

100  =  0  +  50  +  50  +  50 

(1+i)-  (l+iy  (l+i)*  (l+i)>  (1+i)^ 
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STATUS  QUO  WORKSHEET 
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BREAK-EVEN  WORKSHEET 
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SUMMARY  WORKSHEET 


ECONOMIC  ASSESSMENT  SUMMARY  WORKSHEET  mcb _ or _ 


ANALVm  _ TOTAL  COST  OR  UNIFORM  ANNUAL  COST  DATE; 
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ECONOMIC  REPORT 


Section  Description 

I.O  Overview 

1.1  Background 

1.2  Scope 

1 .3  Major  Assumptions 

1 .4  K^jor  Constraints 

2.0  Alternatives 

3.0  Summaiy 

3.1  Cost  Summaiy 

3.2  Benefit  Summaiy 

3.3  Sensitivi^  Analysis  Summary 

3.4  Risk  Analysis  Summary 

3.5  Summary  of  Recommendations 

3.6  Program/Project  Mgmt  Charter 

4.0  Analyses 

4. 1  Bene  fit  Analysb 

4.2  Sensitivity  Analysis 

4.3  Risk  Analysis 

4.4  Conclusion 

4.5  Cost  Data  Sheets 

4.6  Variable  Explanation  Sheets 
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COST  MODELS  (VOLUME  II) 

•  RESIZE  COMPTEK:  JOHN  CLARK,  MIKE  WOOD 

•  REVIC  (TO  BE  SUPPLIED) 

•  PRICE  S  MARTIN  MARIETTA  PRICE  S;  JIM  OTTE 

•  SEER-SEM  GALORATH:  ALAN  CLARK,  KAREN  MC  RITCHIE 

•  SLIM  QSM:  DOUG  PUTNAM,  LARRY  PUTNAM  JR. 

•  SOFTCOST-00  RESOURCE  CALCULATIONS:  TONY  COLLINS 

•  CHECKPOINT  SW  PROD.  RESEARCH:  CAPERS  JONES 
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MANAGEMENT  DECISION  PROCESS 


•  Purpose:  To  combine  quantitative  data  Iron  the  Technical  Assessmsnt 
Process,  Economic  Assessment  Process,  and  subjective  organizational 
data  into  a  repertable  format  for  consistent  reengineering  project 
implementation  decisions 

•  Quantitative  vs.  Subjective  Decision  Criteria 

-  No  direct  correlation  established  between  quantitative  data  and  optimum 
strategy 

-  Create  a  balance  between  these  two  issues 

•  Decision  Process  consists  of: 

-  Management  Report  Preparation 

-  Decision  Process 

-  Decision  Documentation 
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MANAGEMENT  DECISION  (cont.) 

Management  Report  Preparation 

-  Complete  Detailed  Assessment  Results  Worksheet 

-  System  Information 

-  Strategy  Information 

-  Recommended  Ranking 
Executive  Overview 

-  Recommended  Strategy  Rank  Worksheet 

-  Ranking  Explanation 

-  Report  Introduction 
Decision  Process 

-  Additional  organizational  factors 

-  Making  the  decision 
Decision  Documentation 

-  Archive  results  for  organizational  calibration  of  SRAH 
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REENGINEERING  ASSESSMENT 
SERVICES 


John  Clark 

-  Comptek  Federal  Systems,  2877  Guardian  Lane,  VA  Beach  VA  23452 
(804)  463-8500  clark@comptek.com 

Mike  Olsem 

-  STSC  /  SAIC,  OOALC/TISEC,  7278  4th  St.,  Hill  AFB,  UT  84056-5205 
(801)  777-5555  ext  3057  or  (801)  825-2655  olsemm@software.hilI.af.mil 
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CURRENT  ACTIVITIES 

•  NRaD,  San  Diego,  CA 

•  NSWCDD,  White  Oak,  MD 

•  NUWCDIV,  Newport,  RI 

•  PM0450&PM0401,  Washington  DC 


2nd  SPC  REENGINEERING  WORKSHOP  JLC-HDBK-SRAH 

SUMMARY 

•  JLC-HDBK-SRAH  VERSION  2.0  RELEASED  FOR  USE 

•  PLACED  ON  THE  CD  AT  THE  STC  IN  APRIL  ‘95 

•  TO  RECEIVE  A  HARDCOPY: 

-  SOFTWARE  TECHNOLOGY  SUPPORT  CENTER 

•  CUSTOMER  SUPPORT:  (801)777-8045 

•  SEND  COMMENTS  TO: 

-  ROBERT  E.  JOHNSON,  Jr. 

SAM/AES  Strategic  C4  Planning 
PENTAGON  ROOM  1D148 
WASHINGTON,  DC  20310-0107 

VOICE:  (703)697-5397 
FAX:  (703)697-3477 

EMAIL:  johnsonr@comm.hq.af.nul 
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THE  RELATIONSHIP  BETWEEN  APPLICATION  DEVELOPMENT, 

MAINTENANCE,  AND  REENGINEERING 
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Introduction 


Motivation 

•Goal:  Evolutionary  development 
•Problem:  Legacy  systems 
•Approach:  Reengineering 

-  Engineering:  Constrained  probiem  solving 

-  System:  Full-spectrum  decision  analysis 

-  Software:  Program  understanding  (PU) 

-  Managerial:  Project  management 

-  Economic:  Return  on  investment 


CaifMglt  iMton  UhMfMjr 
Software  Engineering  Inetituto 

Framework 

•Goal:  Classify  PU  technology 

•Developed  in  three  steps: 

1.  Investigate  cognitive  aspects 

2.  Identify  canonical  activities 

3.  Categorize  support  mechanisms 


•For  comparison— ‘not  evaluation 


Camtgit  IMton  Univwiii/ 

Softwir*  Engineering  tnetHute 


Cognitive  aspects 


Cognitive  aspects 

•Multiple  problem  factors 
•Numerous  cognitive  models 

•Program  understanding; 

-  Focuses  on  artifacts  &  relationships 
-Requires  inverse  domain  mapping 
-Aided  by  reverse  engineering 


Cwm0a  Mtlon  UrtMiMiy 

Software  Engineering  tnstituta 


Steps 


Canonical  components 


•Model:  Construct  domain-specific 
models  of  the  application 


•Extract:  Gather  raw  data  from  the 
subject  system 

•Abstract:  Create  abstractions  that 
facilitate  understanding 


CvTwgtoMilonUniMraily 

Soflwara  EnglMtrhtg  InstMuto 


...Canonical  components 


Artifacts 

•Data:  Factual  information  used  as 
basis  for  study  &  reasoning 

•Knowiedge:  The  sum  of  what  is 
known  or  derived 

•information:  Seiectiveiy 
communicated  knowiedge 


CifTW(^  Malm  tMvtmir 

settw.r.EnginwfinginrtHut« _ ^Canonfcal  componetHs 


Activities 


•Data  gathering 


•Knowiedge  organization 


•information  expioration 
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Taxonomy 


Taxonomy 

•Domain  retargetability 
•Scalability 
•Automation  level 


CanMgi*  IMtan  Uniwtrall/ 

Softwara  en0in««rin0  Instltuta 


^Taxonomy 


•Pattern  abstraction  level 
-Program  analysis 
-Plan  recognition 


-Concept  assignment 


CwTw^  IMon  UMvtnlif 

Softww*  Engineering  Institute 


...Taxonomy 


•Toolset  extensibility 
•Cognitive  support 
•Application  domain 
•Interaction  method 


Cuiwoi*  IMIon  UnhwiNf 

Softwtre  Engineering  Inetitute 


...Taxonomy 


•Standards  support 
•Modeling  support 
•Adoption  cost 


•Understanding-ln-the-many  support 
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Summary 


Summaty 


•PU  classification  framework 


•Aid  users  in: 

-Evaluating  claims 
-Assessing  applicability 
-Comparing  approaches 

•Single  perspective  on  reengineering 


CanghUltoXMnnllr 

Enginetring  Inrttuf  _ ...Sutnmaiy 

Future  work 

•Refine  taxonomy 

•Populate  framework 

•Perform  experiments 
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Context:  Formal  Perspective 

(from  Taxonomy  of  Verification  MfithnHs^ 
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'PRODUCTIVITY 


Benefits 


Related  Research  Investigation?^ 
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PROGRAM  MAINTENANCE  TECHNIQUES 
EXPERIENCE  WITH 
LOGICAL  CODE  ANALYSIS 
IN  SOFTWARE  MAINTENANCE,  REUSE 
AND  RE-ENGINEERING 

John  Hart 

Porltus  Software  Services,  Inc. 

304  Concord  Rd 
Billerica,  MA  01821 
508-670-2500 
jmhartQworld.std.com 
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^  experts  in  software  maintenance 


Peritus' 

Sohw^  SwwcM.  he 

Three  Principal  Maintenance  Activities 

♦  Corrective  Maintenance 

-  Fixing  defects  in  existing  software 

♦  Adaptive  Maintenance 

-  Changing  specifications,  reuse,  enhancements 

♦  Perfective  Maintenance 

-  Performance  improvements 

-  More  efficient  memory  and  file  space  usage 

-  Improving  documentation 

-  Simplifying  code  for  maintainability  and  reuse 

♦  Summary:  Maintenance  is  a  challenging  and 
costly  part  of  the  software  life-cycle 
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What  is  Logical  Code  Analysis? 

♦  Determination  of  postconditions  and  weakest 
preconditions  to  determine  code  properties 

-  Requires  simple  predicate  calculus 

♦  Emphasis  is  on  iogical  properties  of  the  code 

-  Not  its  operational  behavior 

♦  Sequentiai  code  oniy  (for  now) 

♦  Basic  theoretical  technique 

-  Dijkstra’s  weakest  precondition  (wp) 

»  Other  work  by  Gries,  Cohen,... 

»  Newer  work  on  parallel  programs 
♦  Chandy  &  MIsra. .. 


«i«;jnih:nevA:5 
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Experience  with  Logical  Analysis 

♦  Our  success  is  due  to: 

-  Analyze  code  rather  than  derive  (synthesize)  code 

-  Apply  analysis  to  code  siices  that  affect  a  limited  number  of 
variabies 

-  Isolate  small  code  segments  likely  to  be  the  root  cause  of  a 
defect  or  limitation 

-  Annotate  code  as  we  analyze  it,  thus  capturing  knowledge 

-  Analyze  conditional  statements:  convoluted  lo^  isthe  root 
cause  of  many  problems 

-  Our  goals  are  modest 

»  Solve  some  problems,  increase  productivity, ... 


...  •xpofts  In  software  maintananca 
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Peritus’ 

First  Simple  Example 

♦  Defect  report 

-  “An  unexpected  err_typeK  event  occurred" 

»  Close  to  a  half  million  lines 

»  A  simple  search  using  UNIX  text  toois  showed  one  place 
where  the  event  variable  was  assigned  to  er  r_typeK 


/* 

event  Is  Initialized  to  0  */ 

1. 

if 

(read.sensor  (Al)  1  1 

2. 

3  read^sensor  (A2 )  1  I 

3. 

read_sen8or(Bl)  1 1 

4. 

lread_Ben8or(B2)  ) 

5. 

if  (read_sensor(Bl)  ) 

€. 

event  **  err_typeK; 

eU:jmh:R«v  A.'S 


•xperts  in  software  maintananes 


Peritus' 
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Logical  Analysis  Example 

♦  Compute  the  “state"  that  results  in  this  value 

♦  Compute  weakest  precondition  {wp) 

-  Using  standard  techniques 

-  Weakest  precondition  is  a  logical  predicate  function 

•  The  first  argument  is  a  program 
»  The  second  argument  is  the  postcondition 

-  wp  gives  the  minimal  precondition  to  yieid  the  postcondition 

»  wp  is  the  necessary  initialization  to  get  the  result 

-  Write 
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Some  Observations 


♦  Warning  -  The  developer  originally  included  these  tests 
for  a  reason 

♦  Operational  analysis  (using  dumps,  debuggers,  test  data, 
and  so  on)  might  not  detect  the  defect 

♦  Risky  assumption:  read.sensor  ( )  may  have  internal 
state,  or  it  could  change  between  the  two  reads 

♦  Defect  resolution  required  both  analysis  and  product 
knowledge 

♦  We  say  that  this  defect  showed  a  case  of  redundant 
testing.  Dead  code  is  similar. 
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Peritus* 

SofMi*  tte 

Conditional  Code:  An  Example 

♦  Complex  conditional  code  from  a  TCP/IP 
implementation 

♦  Complexity  is  due  to  the  complexity  of  the  code 

♦  Defect  reports: 

-  Tosing  packets  when  the  system  is  heavily  loaded” 

-  Difficult  to  reproduce 

-  Passes  the  test  cases  (1 00%  path  coverage) 

♦  A  frequently  called  function  is  suspicious 

-  Processes  incoming  packets 

-  Short  but  poorly  documented 


axparts  in  software  maintanancs 
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First  Step  to  Correct  the  Code 

♦  a,  b,  and  c  define  a  valid  “window”  of  packet  sequence 
numbers 

-  b  must  be  between  a  and  and  c,  w'lth  a  less  than  c 

-  a  and  c  cannot  be  *100  far  apart* 

-  Introduce  a  parameter  N  defining  the  "window  size” 

♦  The  first  if  statement  is  suspicious 

-  Involves  bit  operations  and  comparisons 

-  Bit  expression  comparison  to  0  is  true  exactly  when  a  and  c  have  the 
same  sign 

~  Rewrite  first  if  statement  as: 
if  ({a  <  0  c  <  0) 

II  (a  >«  0  &&  c  >«  0) 

II  (a  <»  0  Cc&  c  >s  0) ) 


da:|mh:A«r  A:i7  •xpoits  in  softwari  iMintananca 
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Compute  WP 

♦  valid_window  returns  either  0  or  1 

♦  Result  depends  only  on  values  of  a,  b,  and  c 

■wp.Cr  ■  valid_window  (a,  b,  c)).(r  ««  0  II  r  mb  i)  m  TRUE 
evaluates  to: 

wp.(r  M  valid_wlndow  (a,  b,  c)).(r  -«  1) 
m  ( (a  <  0  1 1  c  >M  0)  &&  a  <«  b  ft&  b  <«  c) 

II  ( ! (a  <  0  1 1  c  >-  0)  &£  (b  >-  a  1 1  b  <-  c) ) 


ci«4"ih:nw  Alia 
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Observations 

♦  valid_window  accepts  values  of  [a,  b,  c]  such  as 
[0,  32768,  65536] 

-  Test  data  did  not  cover  this  case 

♦  Create  a  parameter  “W”  to  represent  “window  size” 

-  A  small  power  of  2,  i.e.,  32  or  64 

-  Corresponds  to  the  size  of  an  array  holding  data  packets 

♦  Summary 

-  Process  was  not  operational 

~  Some  intuition  and  product  knowledge,  but  logic  was  used  most  to 
create  an  exact  specification  •  almost  identical  to  the  code 

-  New  knowledge  can  be  added  as  annotation 

-  Code  is  simpler 
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Peritus’ 

The  Problem  with  if-then-else 

♦  Loop  did  not  terminate  when  it  should 
while  (Idone)  { Loop  Body } 

Loop  body  is: 

1. 

2. 

3. 

4* 

S. 

€. 

7. 

e. 


if  (Mode  —  0)  ok  >  TRUE  «laa  ok  -  FALSE; 
if  (lok)  { 

if  (Mode  Lo)  ( 

if  (ES  <  QS)  ok  -  TRUE;  } 
if  (Mode  »  Hi  ( 

if  (ES  >  QS)  ok  -  TRUE;  } 

) 

dona  ■  FALSE; 
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Sqh—wSwvwtt.hc  _ 

Analyzing  the  if-then-else  (2) 

{ Use  the  identities:  (p  II  Ip)  and  q  =  (p  II  q) ) 

m  ok 

1 1  ((Mods  ■>«  Lo)  it  (BS  <  QS)) 

II  ((Mode  »  Hi)  it  (ES  >  QS)) 

Combining  these  results: 

wp.(Iilne8  1-20). ok 
.  (Mode  0) 

II  ((Mode  »  Lo)  it  (BS  <  QS)) 

II  ((Mode  BB  Hi)  it  (ES  >  QS)) 

/*  1-7; New  Code)  */ 

ok  B  (Mode  bm  0) 

I  I  ( (Mode  BS  Lo)  it  (ES  <  QS) ) 

II  ((Mode  BS  HI)  it  (ES  >  QS)); 
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Analyzing  the  if-then-else  (3) 

wp. (Lines  8-16). done 
>  ok  kk 

((eHode  Lo)  kk  (£S  <  MS) 

II  (eMode  »»  Hi)  &&  (£S  >  HS)) 

/•  8-16 :New  Code  */ 
done  B  ok  kk 

( (eMode  »»  Lo)  kk  (ES  <  MS) 

II  (eMode  BB  Hi)  kk  (ES  >  MS)); 

-  Latent  defect 

»  done  cannot  be  set  when  ES  is  equal  to  either  ms  or  cs. 

♦  This  could  require  a  modification  changed  to  <-  and  >- 

-  If-then-else  statements  can  be  dangerous 

>•  Especially  when  compounded 
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Strategies  (3) 


♦  Strategy  3.  Show  that  a  Program  is  Correct 

♦  Compute  the  weakest  precondition  to  get 

-  Wp.SaP  «  Q 

-  If  Q  Is  identically  true,  the  program  is  correct 

-  If  Q  is  not  identically  true,  then  the  program  will  fail  with  any 
test  data  that  makes  Q  false. 

♦  State  variables  must  be  initialized  so  as  to  make  q 

be  TRUE 
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Strategies  (4) 

♦  strategy  4.  Show  Two  Programs  are  Equivalent 

-  We  may  rewrite  a  sequence  of  code  to  improve  it  in  some  way, 
even  though  we  do  not  want  to  change  its  behavior 

-  Common  during  code  reengineering 

»  Simpier,  faster,  or  more  maintainable 

-  wp.s.Q  m  vp.B'  .Q 

»  for  all  predicates,  Q 
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1. 

2. 

3-4. 

if  Cl  <  1 

if  OEC  « 

if  NEC 

FR 

»»  FR 

/*  FR  U  NY  •/ 

{  /*  Do  Nothing  */ 

) 

5-ff. 

else 

{  Cl  -  1;  MSG  >  1; 

) 

7. 

a. 

$-10. 

else 

if  OEC  «- 

if  NEC 

NT 

««  NY 

{  /*  Do  Nothing  */ 

> 

11-12. 

else 

(  Cl  «  1;  HS6  «  1; 

) 

13. 

else 

/*  if  OEC  «  NY  */ 

14. 

15-16. 

if  NEC 

if 

FR) 

(OEC  »■ 

FR)  {  /*  Do  Nothing 

*/  ) 

17-16. 

else 

{  C  -  1;  MSG  «  1;  } 

1$. 

20. 

else 

if 

(NEC 

NY) 

21-22. 

if  (OEC 

NY)  {/*  Do  Nothing  */) 

23-24. 

else 

(  Cl  >  1;  HSG  -  1; 

> 
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if-then-eise  Statements  &  Reuse  (2) 

♦  Using  Logical  Analysis,  we  get  the  equivalent: 

if  (Cl  <  1  6&  OEC  NEC  it 

(  OEC  -o  FR  11  OEC  —  NY 
I  I  NEC  »  FR  II  NEC  —  NY  ) ) 

{  Cl  «  Ij  MSG  -  1;  ) 

♦  In  words,  Cl  and  MSG  are  set  to  1  exactly  when: 

-  Cl  is  less  than  1, 

-  OEC  and  nec  are  different,  and 

-  at  least  one  of  OEC  and  nec  is  fr  or  NY 
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Strview.  he  _ 

Loops 

♦  Must  determine  a  loop  invariant 

-  An  invariant  predicate  at  both  beginning  and  end  of  the  loop  body. 
Invariant  may  be  parameterized  by  a  loop  index 

-  General  scheme 


/* 

General  form  of  a  loop 

♦/ 

/* 

B  is  a  logical  "guard"' 

*/ 

/* 

S  is  the  loop  body 

*/ 

/♦ 

I  is  an  invariant  of  the 

loop 

*/ 

/♦* 

Initialize  so  that  I  is 

TRUE 

*/ 

while  (B)  {  /** 

I  &&  B 

s  /** 

X 

♦/ 

} 

/** 

I  &&  !B 

*/ 

ciK)mh;Rfv  A:37 
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Loops  (2) 


♦  Correctness  requires 

I  &&  B  «e>  wp.6*X 

♦  Must  be  identically  true  if  the  program  is  to  be 
correct 

♦  If  it  is  not  identically  true,  state  values  that  make 
it  FALSE  will  help  to  determine  test  points  that  will 
cause  defects 
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Detecting  Loop  Defects  (2) 


♦  Computing  the  postcondition  now  shows  that  i  ==  n 

X  !B 

.  0  <«  k  <  j  «»>  Alkl  <  A[jl 

&&  0  <«  j  <  k  <  N  *«>  A[j]  >=  A[)cl  &&  0  <«  j  <  i  e  N 

B  The  program  specification 
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Detecting  Loop  Defects  (3) 

♦  Test  2:  Is  the  invariant  initialized?  The  answer  is  no 

-  j  and  1  are  the  same. 

-  Initializing  i  to  l  quickly  fixes  this  problem 

♦  Test  3:  Does  the  invariant  implication  hold? 

-  Compute  and  simplify  the  implication.  Is  it  identically  TRUE? 

-  Let  s  denote  the  loop  body.  Evaluate; 

I  a&  B  -»  wp.s.l  This  should  be  identically  TRUE 

-  In  this  case,  it  is  not.  FALSE  when  a  [1]  »  afi-l]  &&  j  »  1 

-  Giving  the  last  bug  (the  comparison)  and  correct  program 
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Example 


2.1  1-0; 

1.2  while  (1  <  MTRT/HZ  { 

1.3  /*  Every  time  the  loop  body  executes,  either 

1.4  1)  There  is  a  delay  of  time  HZ,  or 

2.5  2)  We  exit  the  loop  */ 

2.0  if  (LF(dev})  { 

3.1  if  (ILPWCdev)) 

3 . 2  break; 

4.0  }  else 

5.0  delay  (HZ); 

6.1  i  -  i  +  Is 

6.2  } 

7.2  /*  1  >-  MTRT/HZ  or  we  exited  loop  at  line  3.2  */ 

7.2  if  (i  >=  MTRT/HZ)  error_m8g  (252); 
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Example 


♦  Does  that  help? 

It  might!  Part  of  the  problem  Is  that  the  “break”  at 
line  3.2  violates  structured  code  principles.  We 
can  fix  that  as  follows: 
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Example 


1.1 

1.2 

1.3 

1.4 

1.5 
l.€ 
2.1 

3.1 

4.1 

6.1 
6.2 

7.1 

7.2 


i  «  0; 

exit  »  FALSE; 

while  (i  <  MTRT/HZ  £6  lexit)  { 

/*  Every  time  the  loop  body  executes,  either 

1)  There  is  a  delay  of  time  HZ,  or 

2)  We  exit  the  loop  */ 

if  (LP(dev)  &&  ILPW{dev))  {exit  «  TRUE} 

if  {LP(dev)  LPW(dev))  {  } 
if  (ILP(dev))  {delay  HZ) 

i  B  i  1; 

} 

/*  i  >*  HTRT/HZ  I  I  exit  */ 

if  (!exit)  errorjEsg(252) ; 
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Example 


♦  Now  It  is  clear  that  our  assumptions  (as  expressed 
in  the  comment)  about  the  loop  body  are  not  valid. 
The  fix  is  easy. 

♦  NOTE:  This  defect  occurred  in  some  real  OS 
code.  Using  operational  techniques,  the  defect 
was  unresolved  for  a  long  time. 
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Future  Work 

♦  Continuous  improvement  of  our  training  materials 
and  methodologies 

♦  Development  of  logical  analysis  tools  to  be  part  of 
software  toolkits 

♦  Extending  the  application  of  our  techniques  to 
concurrent  programs 
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BPR  Products 
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Measures  of  Merit,  Estimates  of  Improved  Performance  and  Impact  on  Stakeholders. 
Prototype  Results,  Issues  (Problems,  Deficiencies,  Opportunities) 


Interaction  Diagram 
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Benchmarking  (at  high  process  level)  Suggests 
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Classes  of  Requirements  —  Format/Tools 
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Determine  How  Changes  Will  “disturb” 
Different  Classes  of  Stakeholders 
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Activity  Based  Costing  (ABC)  and 
Functional  Economic  Analysis 
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Project  Results  (w.r.t.  Measurable  Goals)  for 
Different  Scenarios 
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More  Project  Activities  [ «  20%  resources  to 
understand  current  process] 
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4.  RESULTS 


At  the  end  of  the  workshop,  each  participant  was  asked  to  list  the  topics  that  interested  her  or  him.  The  topics 
were  collected  and  presented  to  the  participants.  Each  participant  was  then  asked  to  vote  on  the  three  topics 
that  most  interested  her  or  him.  The  following  table  lists  the  topics  and  the  number  of  votes  assigned  to  each 
topic. 


Topic 

Number  of  Votes 

Topic 

Number  of  Votes 

Potholes  and  Pitfalls  of 
Reengineering 

3 

Code  Translation 

3 

Tools  Experience 

9 

User  Interface  Reengineering 

6 

BPR  and  Software 

Engineering  Relationship 

6 

Metrics 

3 

Systems  Reengineering 

8 

“Wrapped”  Legacy  System 
Reengineering 

0 

Transition  Planning 

11 

Product  Lines 

4 

COTS 

9 

How  Much 

2 

Planning 

13 

Methods — 00 

3 

Methods — CS 

3 

Reengineering  Cost/Benefit 
Analysis 

14 

Furthermore,  the  following  World  Wide  Web  sites  were  identified  as  useful  sources  of  reengineering 
information: 

•  www.afmc.wpafb.af.mil 

•  www.reengineer.org/fonim 

•  www.sei.cmu.edu/~reengineering 

•  www.softwre.org 
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The  following  is  an  alphabetical  list  of  all  attendees  of  the  Second  Software  Productivity  Consortium 
Reengineering  Workshop. 


Name 

Aiken,  Peter 

Organization 

Virginia  Commonwealth  University 

Address 
(804)  828-0174 
peuken@caball.vcu.edu 

Bohan,  Jennifer 

Vitro  Corporation 

(703)  418-8275 
bohanj  @  vitro.com 

Chikofsky,  Elliot 

DMR  Group,  Inc. 

(617)  272-0049 
e.chikofsky  @computer.org 

Clark,  John 

Comptek  Federal  Systems,  Inc. 

Va.  Beach  Engineering  Services 

(804)  463-8500  x316 
clark@comptek.com 

Davis,  Ted 

Software  Productivity  Consortium 
Reuse  &  Reengineering  Project 

(703)  742-7335 
davis  @  software,  org 

Evers,  Ed 

CACI 

CACI  Advanced  Technology  Center 

(703)  841-7838 
eevers@hq.caci.com 

Facemire,  Jeff 

Software  Productivity  Consortium 
Reuse  &  Reengineering  Project 

(703)  742-7189 
facemire  @  software.org 

Fee,  Sandra  J. 

Vitro  Corporation 

Software  Center  of  Excellence 

(301)231-1403 

fee@vitro.com 

Feerrar,  Caterine  M. 

Vitro  Corporation 

AUA-11 

(301)  738-5314 
feerrar  @  vitro.com 

Gerritsen,  Douglas 

U.  S.  Army 

Armaments  R&D  Center 

(201)  724-3587 
dgerrit@pica.army.mil 

Gracza,  John  W. 

CASE  Associates,  Inc. 

(703)  978-7120 
cai  @  teleport.com 

Graves,  Robert 

Vitro  Corporation 

Advanced  Software  Technology 

(301)  231-3126 
gravesr  @  vitro.com 
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Name 
Greene,  Robert 

Organization 

Lockheed  Martin  Corporation 

EPI  Center 

Address 
(609)  338-3465 

greene@esc.camden.mmc.com 

Hart,  Johnson  M. 

Peritus  Software  Services 

(508)670-2500x223 
jmhart  @  world.std.com 

Johnson,  Robert  E. 

Single  Agency  Manager  (SAM) 

(703)  697-5397 

robert.johnson  @comm.hq.af.mil 

Krotnholz,  Alfred 

Software  Productivity  Consortium 

Reuse  &  Reengineering  Project 

(703)  742-7274 
kromholz@software.org 

Linger,  Rick 

Software  Engineering  Institute 

(301)  926-4858 
rlinger@sei.cmu.edu 

Martin,  Pauline  F. 

Vitro  Corporation 

SP 

(301)  231-3129 
martinpf@vitro.com 

McCreary,  Julia 

Internal  Revenue  Service 

Data  Administration  &  Design  Planning 

(703)  235-2755 

julia.mccreaiy@ccmial.irs.gov 

McGowan,  Clem 

The  MITRE  Corporation 

(703)  883-7099 
mcgowan@mitie.org 

Mutafelija,  Boris 

Northrop  Grumman 

Data  Systems  &  Services  Division 

(703)  713-4174 

borism@gateway.grumman.com 

O’Grady,  Jim 

GDE  Systems 

Advanced  Engineering  Techology 

(619)  592-5079 
ogrady@gdesystems.com 

Phisterer,  Cathy 

CACI 

IT  Company  -  Federal 

(703)  277-6768 
cphisterere  @  std.caci  .com 

Rose,  Anne 

University  of  Maryland 

Human-Computer  Interaction  Lab 

(301)  405-2757 
rose@cs.umd.edu 

Sharon,  David 

CASE  Associates,  Inc. 

(503)  656-0986 
cai  @teleport.com 

Sisson,  Philip 

Lockheed  Martin 

(703)  264-6433 
sisson.phil  @  ist.vf.mmc.com 

Sutherland,  David 

Lockheed  Martin  Corporation 

Information  Systems  Company 

(407)  826-7956 

Tilley,  Scott  R, 

Software  Engineering  Institute 

Carnegie  Mellon  University 

(712)  268-7157 
stilley  @  sei.cmu.edu 

Ulery,  Bradford  T. 

The  MITRE  Corporation 

(703)  883-3313 
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Name 

Organization 

Software  Engineering  Center 

Address 

bulery  @  mitre.org 

West,  Stacy 

Vitro  Corporation 

SP 

(301)  231-2543 
westsl  @  vitro.com 

Wetzel,  Paul 

Vitro  Corporation 

Advanced  Software  Technology 

(301)  231-3095 
wetzel  @  vitro.com 

White,  Karen 

TASC 

(617)  942-2000  x2654 
krwhite@tasc.com 

Wilson,  Mark 

NSWC  White  Oak 

Naval  Surface  Warfare  Center 

(301)  394-5099 
mlwilso@relay.nswc.navy.mil 
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APPENDIX  B.  WORKSHOP  AGENDA 


The  following  is  the  final  agenda  of  the  Second  Software  Productivity  Consortium  Reengineering 
Workshop. 

MONDAY,  DECEMBER  4, 1995 


8:15  -  8:35 

8:35-9:15 

9:15  -  9:25 

9:25  -  10:10 

10:10  - 10:25 
10:25-11:55 


11:55-12:25 


12:25-1:25 

1:25-2:40 


2:40-2:55 
2:55  -  3:55 


3:55-4:25 


4:25-5:00 


Welcome  and  Introduction 

The  IS  Reengineering  Spectrum: 

Terms,  Approaches,  Methods,  Tools 
Software  Productivity  Consortium 

SPC’s  Product-Line  Approach 

Break 

IS  Reengineering  Experience  Reports 

-  Internal  Revenue  Service 

-  Integrating  Domain  Engr.  and  Reengr. 

-  Others 

-  Discussion 

Reengineering  of  User  Interfaces 

-  UI  Reengineering  at  Maryland 
Lunch 

Data  Reengineering 

-  Focus:  Data  Reengineering 

-  Discussion 
Break 

Reengineering  Economics 

-  Software  Reengr.  Assessment  Handbook 

-  Discussion 

Tools  for  Reengineering 

-  Classifying  Tools  for  Reengineering 
State  of  the  Industry 

What  We  Heard:  Summary  Discussion 
of  the  Day  (all  attendees) 


J.  Facemire,  the  Software  Productivity 
Consortium 

E.  Chikofsky,  DMR  Group 

A.  Pyster,  the  Software  Productivity 
Consortium 

J.  Facemire,  the  Software  Productivity 
Consortium 

E.  Chikofsky,  DMR  Group 
(moderator) 

J.  McCreary,  IRS 
N.  Pry  wes,  CCCC/U  Pa 

J.  Facemire,  the  Software  Productivity 
Consortium  (moderator) 

A.  Rose,  Univ.  of  Maryland 

E.  Chikofsky,  DMR  Group 
(moderator) 

P.  Aiken,  VA  Commw  U 


J.  Facemire,  the  Software  Productivity 
Consortium  (moderator) 

J.  Clark,  Comptek 

E.  Chikofsky,  DMR  Group 
(moderator) 

D.  Sharon,  CASE  Assoc. 

J.  Facemire,  the  Software  Productivity 
Consortium 

E.  Chikofsky,  DMR  Group 
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Appendix  B.  Workshop  Agenda 


TUESDAY,  DECEMBER  5, 1995 


8:15  -  9:15  Object  Technology  in  Reengineering 

-  Enterprise  Solutions  with  Objects 
(demo) 

-  Discussion 

9:15  -  10:30  Reverse  Engineering 


-  Framework  for  Progr.  Understanding 

-  Rev  Engr.  Code  into  Requirements 
(include  Logical  Code  Analysis) 

-  Discussion 
10:30-10:45  Break 

10:45  -  12:00  Reengineering  Information  Systems 

-  Recap:  SPC’s  Product  Line  Approach 

12:00  -  1:45  Reengineering  Information  Systems 


-  Bridging  Gap  Betw  BPR  and  SW  Syst. 

-  Discussion 

1 :45  -  2:45  What  We  Heard  and  What  We  Need 

Summary  Disc,  and  Prioritization 

2:45  -  3:00  Closing  Remarks/Adjoum 


M.  Blackburn,  the  Software  Productivity 
Consortium  (moderator) 

R.  Maroney,  Template  SW 


E.  Chikofsky,  DMR  Group 
(moderator) 

S.  Tilley,  SEI 

M.  Blackburn,  the  Software  Productivity 

Consortium 

J.  Hart,  Peritus 

A.  Kromholz,  the.  Software  Productivity 
Consortium  (moderator) 

J.  Facemire,  the  Software  Productivity 
Consortium 

A.  Kromholz,  the  Software  Productivity 
Consortium  (moderator) 

C.  McGowan,  MITRE 

J.  Facemire,  the  Software  Productivity 
Consortium 

E.  Chikofsky,  DMR  Group 

J.  Facemire,  the  Software  Productivity 

Consortium 
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